Astro DB
astro.buildComments coming from a years-long Astro user that loves it. I use it to power my own website. I'm familiar with this space because I also work at Xata (take that as a disclosure).
This looks like a pretty simple data solution that might work for Astro's audience (content sites and hobbyists). They've split the hosting into their studio product to provide a way to earn revenue. Essentially you host the DB with them and can access it remotely, but could also host it however you want, you'd just lose the Studio editor.
The Studio editor itself is pretty basic at the moment with a table view and a way to check SQL calls. You can't build schemas in the UI yet and what you get is mostly a dev wrap of existing tools (like Drizzle) that let you interact with your DB. Their demo shows the limitations here, with things like "email" not being able to validate in the studio editor. My guess is that's coming later, but I might have missed it in the docs. Either way, it's nice that your config is stored at the code layer.
Most of these small websites that Astro is great fit need small CMS systems, and studio doesn't look to provide any way to deal with images (at least on first check) so that's sort of a bummer. You'd need to wire up some references with Cloudflare I guess. Still reading here, but it'd be cool if that came natively. Storing, retrieving and resizing images is a pain. The column types allowed are pretty small (text, number, bool, date, json).
While simple. It looks like it'll be relatively speedy with retrieval because of it.
Right now though, as an actual CMS editor (which my guess is what most Astro folks really want) Studio feels way to simple to tell a client to use. I'm interested to see whether they go more in the direction of a generic database store (implied from the name) or more of a CMS to compete with the natural pairings of Contentful, Statamic and others. Webhooks as a launch feature is great! That'll help folks out.
Either way. I love this team and their perspective. They build cool stuff, open source a lot of it (check out Starlight for docs), and I'm excited to see where this one goes over time. Congrats on the launch.
Now I need to update my Astro site to 4.5 :)
> a years-long Astro user that loves it
Have you tried Eleventy? If you have, how, in your opinion, does Astro compare?
Been awhile with eleventy, but I really like the "islands" concept from Astro. It lets me break out into Svelte when I need for server stuff. Astro is also excellent at building shiki, TS and content generation together natively.
Overall it feels a little less bare bones, while still being flexible.
I get that all of the current generation of front-end/back-end frameworks promised their investors that they'd figure out how to sell developer services, rather than just offer open-source components with some extra commercial support options...
But I do wonder how this type of thing will actually compete against a billion headless CMSes and a million PaaSes already on the market...
> But I do wonder how this type of thing will actually compete against a billion headless CMSes and a million PaaSes already on the market...
They won't. I, for one, hate that runtimes like Deno and frameworks like Astro start offering paid infrastructure. This smells like lock-in from a million years away.
> smells like lock-in from a million years away.
I worry too, but here you can export as sql and csv.
Love that they use comments as an example. I miss this with many static blogs. HN comments are great, but I sometimes want to read a discussion between people who've actually read the article.
Hey, I'm one of Astro's co-creators, happy to take any questions on Astro DB you may have!
Hi Matthew. Both Cloudflare[1] and Turso[2] have apparently very similar offerings at what appears to be better pricing. What does AstroDB provide to warrant the additional cost?
[1]: https://developers.cloudflare.com/d1/platform/pricing/+----------+------------------------+----------------+---------------+ | | Base Storage + Cost/GB | Reads | Writes | +----------+------------------------+----------------+---------------+ | Astro DB | 1GB + $1.00 | 1b + $0.001/m | 1m + $1.00/m | | D1 Free | 5GB | 150m | 3m | | D1 Paid | 5GB + $0.75 | 25b + $0.001/m | 50m + $1.00/m | | Turso | 9GB + $0.75 | 1b + $0.001/m | 25m + $1.00/m | +----------+------------------------+----------------+---------------+First, we have just launched and are still figuring out pricing, this is a great point of feedback that we'll consider, thank you.
What differentiates Astro DB is the deep integration with the Astro framework and providing an easy path for common scenarios. Astro DB is a higher-level product than using a database service directly. For example, Astro DB handles migrations transparently for you and guides you when manual intervention is needed, just from running `astro db push`.
Astro DB also includes a local story, by default you use a local SQLite database that you can seed (using db/seed.ts) for local development. You can even use it for a purely static site, although we're still working on making SSG use-cases more seamless. For now though, this gives you a great local workflow for development that you can think easily connect to production with `astro build --remote`.
I dig Astro and use it to build my blog and several other tiny mostly-static sites. I'm not sure that the hosted database service fills a need I have but, in general, supported SQL integration seems like a useful addition.
As an aside: there are days when I wish I could avoid using the Astro component model entirely, do everything in Preact (or whatever), and still use the `client:*` directives when appropriate. I realize this is easier said than done and also probably not a reasonable thing for Astro itself to try and target -- but moving between Astro components and framework components always has just enough friction that it's something I think I'd enjoy using.
This is probably the main reason I wouldn’t choose Astro for personal projects where it’s otherwise a great fit. I think it would have been a more reasonable thing earlier on in product conception, but quite a lot of assumptions are now baked into their own custom template language. Which I’m sure is quite a nice template language, but it’s already hard enough to get all the tools to work nicely together without adding another one.
Yeah, I started poking at Vite to see how much work it would take to build an island-architecture-for-preact tool on top of it. It looks doable.
Out of curiosity, when you're building a mostly static site that might want occasional islands of interactivity, what do you reach for instead?
> mostly static site that might want occasional islands of interactivity
is exactly what I made this for https://github.com/bensmithett/tropical-utils/tree/main/pack...
It’s a little more verbose and doesn’t quite have the ergonomics of Astro client:* directives, but it does the trick for me.
How is something like this or other services like cloudflare's D1 an actual scalable solution for any serious app? Is it the pattern where you give every customer, team or "workspace" it's own database and manage this through some distributed kv store? I am just trying to understand how this is a relevant solution and not some weird SQLlite fetishism you see going around.
A lot of Astro news for the last 2 days:
- 4.5 release
- Volar $10,000 grant
- Astro Studio/DB
They call these "launch weeks"
Ah, so that's why. I wonder what we get on wednesday. Maybe CMS?
So what's the added value over Turso + Drizzle?
It seems to be wrapping drizzle, with astrodb just being a way to deeper integrate it into the framework and adding some ease of use features. Also seems like a nice way to support the development of astro by using their hosting service.
So it is the wrapper for wrapper (Drizzle) for Kysely?
As far as I can see from looking at their repo, Drizzle isn't a wrapper for Kysely though? You can use Kysely or other query builders with drizzle, but it has its own query builder too.
Astro on a roll lately! Excited for the rest of Launch Week
What do they do to mitigate the roundtrip latency introduced by using a hosted database on a separate network? Is the idea that you wouldn't use this if you have pages that do many queries to render?
This is a very good question! One of the big reasons we partnered with Turso was for their edge network, so replicas are available close to your origin server. Being able to host anywhere is something that's important to Astro, so this felt like the right balance. Turso is known for its speed and one of the main thing that attracts people to use it.
Gotcha, so you guys use readonly edge servers and just eat the latency on writes
The ORM API is very reminiscent of Drizzle, which I think was a great call on Astro's side. I have so far only used Astro for SSG, but seeing code like this [1] has me interested to see how far it can go for SSR tasks that you might currently use metaframeworks such as Next/Nuxt/SolidStart/SvelteKit for.
It actually is Drizzle
I'm currently thinking about using either Astro or SvelteKit for my next project. Astro DB suggests that Astro aims to be more than just a static site builder. However, all over the internet, I read that Astro is primarily a static site builder, and if I want to build a fully-featured web application, I should use something like Next.js or SvelteKit. Now, I'm a little bit confused where Astro DB fits into this picture.
It used to be a nice site builder, for static sites and apps, but has grown into another full-featured framework of sorts. And is now sliding into SaaS.
Interesting and even more compelling pricing, indeed a very generous free tier.
I only wish this wasn't a javascript heavy thing and that I could interface with it in my language of choice. But as it says on the tin this is integrated well for the greater Astro ecosystem.
It's only a matter of time until someone reverse-engineers the API, and then you're free to port it to any language you like.
However, I think Turso & Cloudflare D1 currently have slightly better pricing.
Slightly tangential -- anyone knows how does libSQL compare to upstream SQLite for shipping with a desktop app or in the browser via wasm?
Edit: I've read the readme, hoping for a take from anyone who gave it a try
Personally, I love Astro and use it personally (and at work). I hope this turns out as a great start to generating revenue.
so it is basically using libSQL instead of SQLlite?
Had to look this one up, "libSQL" is the name of Turso's own one-way-compatible fork of SQLite.
It does use libSQL, yes!
why are they calling a CMS a DB?
Not to be confused with Astra DB, Cassandra as a Service.. http://astra.datastax.com
FWIW, Astra (DataStax) is more than just Cassandra as a Service. Other features include search and graph database support. An open-source "equivalent" would be Cassandra, JanusGraph, and Lucene.