Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Astro DB

astro.build

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Astro DB

#21

Post by explodingcamera »

mati365 wrote: post #18
explodingcamera wrote: post #3

Earlier quoted context omitted.

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.

Re: Astro DB

#23

Post by jer0me »

seabass wrote: post #16

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. [1] https://docs.astro.build/en/guides/astro-db/#insert

It actually is Drizzle

Re: Astro DB

#26

Post by MatthewPhillips »

LostLocalMan wrote: post #20

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.

Re: Astro DB

#27

Post by internetter »

MatthewPhillips wrote: post #19

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?

  +----------+------------------------+----------------+---------------+
  |          | 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 |
  +----------+------------------------+----------------+---------------+
[1]: https://developers.cloudflare.com/d1/platform/pricing/

[2]: https://turso.tech/pricing

Re: Astro DB

#28

Post by bensmithett »

davepeck wrote: post #17
eyelidlessness wrote: post #12

Earlier quoted context omitted.

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 addi…

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.

Re: Astro DB

#29

Post by LostLocalMan »

MatthewPhillips wrote: post #26
LostLocalMan wrote: post #20

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

Re: Astro DB

#30

Post by MatthewPhillips »

internetter wrote: post #27
MatthewPhillips wrote: post #19

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? +----------+------------------------+----------------+---------------+ | | Base Storage + Cost/GB | Reads | Writes | +----------+------------------------+----------------+---------------+ | Astro DB | 1GB + $1.00 | 1b + $0.001/m | 1m + $1.00…

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`.

Post reply on HN