Bunny Database
bunny.net
bunny.net
> 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.
Company apologises for delay.
The comedic timing is insane.
Company apologises for delay.
The comedic timing is insane.
..internet user points out said comedy.
..Company backtracks on initial apology and s3 access rollout plans and commits to providing immediate s3 access through social media thread replies.
Asking because I was looking at both Cloudflare and Bunny literally this week...and I feel like I don't know anything about it. Googling for it, with "hackernews" as keyword to avoid all the blogspam, didn't bring up all that much.
(I ended up with Cloudflare and am sure that for my purposes it doesn't matter at all which I choose.)
- The free CDN is basically unusable with my ISP Telekom Germany due to a long-running and well documented peering dispute. This is not necessarily an issue with Cloudflare itself, but means that I have to pay for the Pro plan for every domain if I want to have a functioning site in my home country. The $25 per domain / project add up.
- Cloudflare recently had repeated, long outages that took down my projects for hours at a time.
- Their database offering (D1) had some unpredictable latency spikes that I never managed to fully track down.
- As a European, I'm trying to minimize the money I spent on US cloud services and am actively looking for European alternatives.
However, at the time I did plenty of trace routes to confirm that the Pro plans peering is at least better than the Free plan for the Telekom problem. Free plan would route traffic to NYC and back, while Pro plan traffic terminates in Frankfurt.
> When S3 compatibility is enabled (currently in beta), the number of available replication points is reduced
I assume it's a private beta.
https://docs.bunny.net/storage/storage-tiers#s3-compatibilit...
> This feature is currently in the closed beta stage. It is not available for use currently, but it's expected to be in the near future. We appreciate your interest in it and will mark your ticket so we can notify you when it's available.
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.
Thank you for your update, it's really appreaciated, it will be good to get this sorted :) It sounds like quite a challenge you're working on with the ingest and backlog!
Hopefully it will be fixed soon.
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
It depends:
- do you want multi region presence
- do you want snapshot backups
- do you want automated replication
- do you want transparent failover
- do you want load balancing of queries
- do you want online schema migrations with millisecond lock time
- do you want easy reverts in time
- do you want minor versions automatically managed
- do you want the auth integrated with a different existing system
- do you want...
There's a lot that hosted services with extra features can give you. You can do everything on the list yourself of course, but it will take time and unless you already have experience, every point can introduce some failure you're not aware of.
I totally agree with that, but in my experience 99% of "application developers" don't need all these features. Of those you listed, I only see "backups" as a requirement. Everything else is just - what I said - features for when your application is successful and you want something streamlined.
I would have concerns around backups (ensuring that your backups are actually working, secure, and reliable seems like potentially time intensive ongoing work).
I also don't think I fully understand what is required in terms of security. Do I now have to keep track of CVEs, and work out what actions I need to in response to each one? You talk about firewall rules. I don't know what is required here either.
I'm sure it's not too hard to hire someone who does know how to do these things, but probably not for anything close to the $50/month or whatever it costs to run a hosted database.
It is not. You can provision a free Postgres instance with a single click: https://neon.new/
And tell me how easily you can achieve this "out of the box"
If you don't care about business continuity or high availability then everything gets easier
> And neither MySQL or Postgres ever seem to go down, they're super reliable and stable
The box they're on goes down
So? Not everyone needs 99.999999% availability.
Serverless, managed databases and even multicloud won't save you. You'll still have to be on call.
Don't want to be on call? Design your stuff so it works local first.
Sure, any regular SME can just install Postgres or MySQL without even setting much up except with `mysql_secure_install`, a user with a password and an 'app' database. But you may end up with 10-20 database installs you need to back up, patch and so on every once in a while. And companies value that.
Cloudflare, Fly.io litestream offerings and Turso are pretty reasonably priced, given the global coverage.
AWS with Aurora is more expensive for sure and isn’t edge located if I recall correctly, so you don’t get near instant propagation of changes on the edge
The bigger thing for me is how much control you have. So far with these edge database providers you don’t have a ton of say in how things are structured. To use them optimally, I have found it works best if you are doing database-per-tenant (or customer) scenarios or using it as a read / write cache that gets exfiltrated asynchronously.
And that is where I believe the real cost factors come into play is the flexibility
I setup a cron job to store my backups to object storage but everything felt very fragile because if any detail in the chain was misconfigured I'd basically have a broken production database. I'd have to watch the database constantly or setup alerts and notifications.
If there is a ready to go OSS postgres with backups configured you can deploy I'd happily pay them for that.
What is the upgrade path?
How often do they release?
Do I have to worry about CVEs?
Who is doing network security?
Who is testing that security?
Where are my credentials stored?
Do I have a dashboard that tracks the hundreds of resources I'm responsible for including this new one?
> Plus you have very stable costs each month
I'm sick and tired of managing linux boxes. It simply doesn't scale in any reasonable way.
I've been had :(
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)I was testing IPv6 origin support (they don’t support it), and they billed me $2 for a couple of test requests. I was testing at the end of the month.
With other providers, this would have cost only a few cents.
They don't elaborate, but apparently libSQL has an HTTP API called "Hrana": https://github.com/tursodatabase/libsql/blob/main/docs/HRANA... - if that's what they're exposing, wouldn't it make more sense to call it libSQL-compatible or something?
I tried to test it out as a CDN replacement for Cloudflare but the workflow was a lot different. Instead of just using DNS to put it in front of another website and proxy the requests (the "orange cloud" button), I had to upload all the assets to Bunny and then rewrite the URLs in my app. Was kind of a pain
It's a similar process to Cloudflare. Point the NS to them and enable the proxy for a domain or subdomain.
(don't use CNAME flattening with DNS-routed CDNs like Bunny though, if you must use an apex domain then use the CDNs integrated nameservers)
What is the problem with doing that?
Has this situation changed?
I've been trying out Bunny recently and it looks like a very viable replacement for most things I currently do with Cloudflare. This new database fills one of the major gaps.
Their edge scripting is based on Deno, and I think is pretty comparable to e.g. Vercel. They also have "magic containers", comparable to AWS ECS but (I think) much more convenient. It sounds from the docs like they run containers close to the edge, but I don't know if it's comparable to e.g. Lambda@Edge.
Bunny has a similarity concept: https://bunny.net/edge-scripting/
They even support websockets.
Why they cant do is the TUnnel stuff, or at least fake it. I have ipv6 servers, and I can't have the IPv4 Bunny traffic go to the ipv6 only sources.
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?
Even as a managed service, Postgres DBaaS still tends to push users into capacity planning, instance tiers, and paying for idle headroom. Using a SQLite-compatible engine lets us offer a truly usage-based model with affordable read replication and minimal idle costs.
Its European rather than from USA so its less dependent on that orange guy in that white/golden house
Just compare the most recent commits from LibSQL: https://github.com/tursodatabase/libsql/commits/main/
To those of SQLite: https://sqlite.org/src/timeline
One of these looks like a healthy and actively maintained project. The other isn't quite dead, but it's limping along.
https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-go...
S3 compatible storage was an exciting thing to look forward to. But some of their stuff off the shelf was cost effective and worked well
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.
We actually ran a benchmark to see how read latency degrades with distance from the database: https://bunny.net/blog/how-database-location-affects-far-awa...
turso also made it so your primary had to be in one location, but bunny will move it around based on latency on next boot.
Also, not sure about now, but historically Turso didn't have to best uptime.
In addition to the other points brought up, it looks like pricing strongly favors Bunny once you're outside of Cloudflare's free tier.
Per billion rows read: Bunny $0.30, Cloudflare $1.00 (first 25B/month free)
Per million rows written: Bunny $0.30, Cloudflare $1.00 (first 50M/month free)
Per GB stored: Bunny $0.10/region, Cloudflare $0.75 (5GB free)
Bunny also has a lot better region selection, 41 available vs. Cloudflare's 6 (see https://developers.cloudflare.com/d1/configuration/data-loca...). Even though Bunny charges storage per region used where Cloudflare doesn't, Bunny still comes out cheaper with 7 regions selected. Bunny lets you choose how many and which regions to replicate across; Cloudflare's region replication is an on/off toggle that is in beta and requires you to use "the new Sessions API" (I don't know what this entails).
The main reason I haven't tried out D1 is that it locks you into using Workers to access the database. Bunny says they have an HTTP API.
I plan to stick with VPSes for compute and storage, but I do like seeing someone (other than Amazon) challenge Cloudflare on their huge array of fun toys for devs to play with.
It looks like there might be issues in Italy too.
And Cloudflare is an american company.
SQLite is an embedded database. Every Android app for instance gets a db through sqlite for free. You can easily compile it yourself and embed it in pretty much anything that has a CPU.
So you'd like to offload this embeddable database that's nowhere near postgres or even maria, and then it even says:
> Why care about database latency anyway?
Right. Because you can't even begin to think about introducing a network stack between your application and the database unless you can't be bothered at all about the latency.
I can't imagine myself a customer for this.
(Context: <https://xkcd.com/1871/>.)
Nah, who am I kidding. I left.