While in public preview, Bunny Database is free.
When idle, Bunny Database only incurs storage costs. One primary region is charged continuously, while read replicas only add storage costs when serving traffic (metered by the hour).
Reads - $0.30 per billion rows
Writes - $0.30 per million rows
Storage - $0.10 per GB per active region (monthly)
Marek from bunny.net here. Bunny Database works best for read-heavy use cases with fewer concurrent writes. Like SQLite, it follows a single-writer model, so there’s one writer at a time per database.
> Not every project needs Postgres, and that’s okay. Sometimes you just want a simple, reliable database that you can spin up quickly and build on, without worrying it’ll hit your wallet like an EC2.
Isn't the operational burden of SQLite the main selling point over Postgres (not one I subscribe to, but that's neither here nor there)? If it's managed, why do I care if it's SQLite or Postgres? If anything, I would expect Postgres to be the friendlier option, since you won't have to worry about eventually discovering that you actually need some feature even if you don't need it at the start of your project. Maybe there are projects that implement SQLite on top of Postgres so you can gradually migrate away from SQLite if you need Postgres features eventually?
fwiw, Bunny are the people that announced S3 compatibility for their object storage in Q2 2022 [1]
> We can’t wait to have this available as a preview later in Q2 and truly make global storage a breeze, so keep an eye out!
then apologised for missing that in September 2023 [2]
> We initially announced that we were working on S3 support for Bunny Storage all the way back in 2022. Today, as 2023 is slowly coming to an end, many of our customers continue to follow our blog, hoping for good news about the release.
changing the roadmap to early 2024 [2]
> But we are working aggressively toward shipping S3 compatibility in early 2024.
That same post also has the beautiful "At bunny.net, we value transparency." quote.
It's early 2026, and they're literally ignoring my support requests asking about what the roadmap is looking like for this now.
So, do not trust their product or leadership at all.
Jamie from bunny.net here. Apologies for the delay after announcing S3. Building this required deeper changes to our storage foundation than initially anticipated, while ensuring that existing storage customers remained unaffected.
For clarity, S3 compatibility for Bunny Storage is now live in closed preview (since Jan 2026) with a select set of users.
We’ll soon introduce a sign-up page where users can register their interest, and in the next phase we’ll grant access to invited users.
I've been struggling with Bunny the last couple of days.
Their log delivery api is delayed by over 3 days, despite them promising only "up to 5 minutes delay" in their docs: https://docs.bunny.net/cdn/logging
Why isn't it on the status page you might ask? Oh, that's because a delay is not "critical", but I fear I am losing loglines now, their retention is 3 days.
It's an interesting strategy for them, because it doesn't inspire confidence in me about their other offerings. When they can't reliably operate a log delivery API or be transparent about issues, it's hard to trust them with something as critical as a database.
Hey, I’m Joe, Lead of Content Delivery & Security at bunny.net.
We’re currently working through a backlog of approximately 2.5M log files. I’ve spent the last day optimizing our backlog processing pipeline, which has significantly increased throughput.
Based on the current processing rate, we expect the backlog to be fully cleared within the next 12–18 hours (estimate), and real-time log delivery should progressively return closer to real-time as the backlog drains.
Apologies for the inconvenience this has caused. We’re also in the process of migrating away from our existing logging infrastructure to a ClickHouse-based system to significantly improve reliability and throughput and prevent this from happening again.
We’ve published a status page incident and will continue posting updates there as progress is made.
Will give this a spin. They’re one of the few cloud-y providers that has both prepayment and a rate limiter that doesn’t charge for rate limit exceeds (still blows my mind that providers charge for blocks).
Adding my voice to the chorus here: they've established a pattern of introducing new features and never really getting them past the 80% point. No qualms with the CDN; it's a sweet spot among providers. But their other offerings have been frustrating me for years now.
Reminds me of how we got scarred by "parse.com" -- it was also a promising database, and our customer insisted on it, but after lengthy development and just before our project release turned out that they are shutting down and noone works on it anymore. Like literally their support said "uhm sorry folks, we're all hired by Facebook, no one is working on parse.com anymore".
39 comments
[ 21.1 ms ] story [ 928 ms ] threadIsn't the operational burden of SQLite the main selling point over Postgres (not one I subscribe to, but that's neither here nor there)? If it's managed, why do I care if it's SQLite or Postgres? If anything, I would expect Postgres to be the friendlier option, since you won't have to worry about eventually discovering that you actually need some feature even if you don't need it at the start of your project. Maybe there are projects that implement SQLite on top of Postgres so you can gradually migrate away from SQLite if you need Postgres features eventually?
Any Linux distro can have MySQL or Postgres installed in less than five minutes and works out of the box
Even a single core VPS can handle lots of queries per second (assuming the tables are indexed properly and the queries aren't trash)
There are mature open source backup solutions which don't require DB downtime (also available in most package managers)
It's trivial to tune a DB using .conf files (there are even scripts that autotune for you!!!)
Your VPS provider will allow you to configure encryption at rest, firewall rules, and whole disk snapshots as well
And neither MySQL or Postgres ever seem to go down, they're super reliable and stable
Plus you have very stable costs each month
> We can’t wait to have this available as a preview later in Q2 and truly make global storage a breeze, so keep an eye out!
then apologised for missing that in September 2023 [2]
> We initially announced that we were working on S3 support for Bunny Storage all the way back in 2022. Today, as 2023 is slowly coming to an end, many of our customers continue to follow our blog, hoping for good news about the release.
changing the roadmap to early 2024 [2]
> But we are working aggressively toward shipping S3 compatibility in early 2024.
That same post also has the beautiful "At bunny.net, we value transparency." quote. It's early 2026, and they're literally ignoring my support requests asking about what the roadmap is looking like for this now.
So, do not trust their product or leadership at all.
[1] https://bunny.net/blog/introducing-edge-storage-sftp-support... [2] https://bunny.net/blog/whats-happening-with-s3-compatibility...
For clarity, S3 compatibility for Bunny Storage is now live in closed preview (since Jan 2026) with a select set of users.
We’ll soon introduce a sign-up page where users can register their interest, and in the next phase we’ll grant access to invited users.
Their log delivery api is delayed by over 3 days, despite them promising only "up to 5 minutes delay" in their docs: https://docs.bunny.net/cdn/logging
Why isn't it on the status page you might ask? Oh, that's because a delay is not "critical", but I fear I am losing loglines now, their retention is 3 days.
It's an interesting strategy for them, because it doesn't inspire confidence in me about their other offerings. When they can't reliably operate a log delivery API or be transparent about issues, it's hard to trust them with something as critical as a database.
We’re currently working through a backlog of approximately 2.5M log files. I’ve spent the last day optimizing our backlog processing pipeline, which has significantly increased throughput.
Based on the current processing rate, we expect the backlog to be fully cleared within the next 12–18 hours (estimate), and real-time log delivery should progressively return closer to real-time as the backlog drains.
Apologies for the inconvenience this has caused. We’re also in the process of migrating away from our existing logging infrastructure to a ClickHouse-based system to significantly improve reliability and throughput and prevent this from happening again.
We’ve published a status page incident and will continue posting updates there as progress is made.
If not, it seems like it would be quite a bit of work to implement the synchronization... and I don't understand why one would use it otherwise.
Its European rather than from USA so its less dependent on that orange guy in that white/golden house