161–170 of 178 posts
Embedded databases where the db is a single file are the bomb. We build several products in Java using H2 as our database. What a pleasure. Full SQL support, zero configuration/installation/etc. Just copy data-files/dbs around using normal file tools. Just start up one process and your app is ready.
This is my first time hearing about H2, what's the benefit of H2 over sqlite?
I've been building a web service on a cheapo DigitalOcean box lately, so I'm excited to see explorations in this space, especially with an eye towards staying cheap! I'd probably only use this particular tool if it could hook up to Backblaze B2 instead of S3, since life's too short to ever have to engage with the hell that is AWS for a hobby project, but since B2's API-compatible it seems like a feature that could be…
Since the web app runs on a single, always-on dyno, seems like it may work to use Litestream to (1) continuously replicate and (2) restore when we restart the dyno.
For folks who have dug into Litestream further than me, any thoughts on this use case?
(Of course, need to handle starting and supervising Litestream and the web app from one process, per Heroku's 1:1 process-dyno model.)
Coincidentally, I stumbled across an old tweet by Ben (OP/Litestream author) about Heroku and SQLite[1] a month ago, when first thinking of getting the app off Postgres.
[1]: https://twitter.com/benbjohnson/status/1186666174467039233
Edit: typos
If bedrockdb ( https://bedrockdb.com/ ) replicated to object storage like litestream, I’d be in heaven.
With this approach, people have to start sharding their data as soon as one server can't handle their application and sqlite usage. Why not advocate instead for people to start out running their application and postgresql on the same server, with wal-e for backups to S3? That has almost the same benefits while everything fits on one server, but opens up alternative approaches to scaling if one day things no longer fi…
because sqlite is super simple to use and most things won't ever need to scale beyond one server.
Yep. But don't tell anyone. This is a secret weapon/super power most juniors (and many mid/seniors) have been conditioned by the GOOG/FB/AMZN/MSFT approved project literature to believe is simply untrue. The number of experienced, highly skilled founder devs I know that reach for shiny tech stacks that solve issues they don't have but can "scale" is a 100:1. That choice comes with staggering costs.
Earlier quoted context omitted.
They did invent it and name it like this. Is there an issue with calling it Amazon S3? Can't they get credit for it? Even software such as Ceph calls themselves compatible with "Amazon S3 API".
They did not invent object storage so much as popularize it and standardize the terminology we now use. S3 was announced in 2006. By then, many other distributed object stores had already existed for years, mostly for purely archival use and often a bit enterprise-ish (e.g. FilePool/Centera in 2002). Depending on how much similarity you require, you could even trace lineage back to NASD in 1995. There's also a closel…
It's bad from Amazon to not credit predecessors. If previous APIs are that close with S3, adding their branding is problematic.
Earlier quoted context omitted.
I haven't tried Backblaze B2 but I agree with you on engaging in AWS hell. Litestream should work with any S3-compatible API. I've added an issue to add guides for B2 & Minio[1]. Regarding Postgres vs SQLite, I've found that I can use much simpler SQL calls with embedded databases when I don't need to worry about N+1 query performance issues. That makes many of the query features moot. That being said, there is a JSO…
A bit more literature on the N+1 situation in SQLite: https://www.sqlite.org/np1queryprob.html
"Solutions such as Kubernetes tout the benefits of zero-downtime deployments but ignore that their inherent complexity causes availability issues." This is completely accurate. I've seen several teams do kubernetes, only to both spend 50% of their dev time on ops, AND cause outages due to kubernetes complexity. They do this all while boasting about zero downtime deployments. It's comical really.
It truly is. I see the complexity stems from replication of the many OS services applications require. As a result, the containerized ecosystem ends up full circle but reinvented with a leaky abstraction that generates complexity. To me the comical part is how the IT team fails to acknowledge this. Naturally it spreads like cancer. Non k8s native infrastructure is now abandon-ware. All that tech built over the last t…
Once you said this, the is no longer a neccesity to say more. I could not agree more.