191–200 of 349 posts
I've actually started moving away from Postgres to MySQL and SQLite. I don't want to have to deal with the vacuums/maintenance/footguns.
I've actually started moving away from Postgres to MySQL and SQLite. I don't want to have to deal with the vacuums/maintenance/footguns.
It's 20xx just use sqlite. Almost no-one needs all that power; they sure do think they do, but really don't. And will never. SQLite + Duck is all you need even with a million visitors; when you need failover and scaling you need more, but that is a tiny fraction of all companies.
Huh? SQLite is designed for application databases. Postgres is designed for client-server. It's not about "power" (what does that even mean?), it's about totally different design choices that are intended for different purposes. It's an architecture question, not a "power" or "visitors" question.
I’m a huge Postgres fan. That said, I don’t agree with the blanket advice of “just use Postgres.” That stance often comes from folks who haven’t been exposed enough to (newer) purpose-built technologies and the tremendous value they can create The argument, as in this blog, is that a single Postgres stack is simpler and reduces complexity. What’s often overlooked is the CAPEX and OPEX required to make Postgres work w…
Exactly. Use cases differ. https://www.geeksforgeeks.org/mysql/difference-between-mysql...
PGlite would be perfect if only it allowed multiple writer connections. SQLite is ok but I want PG extensions and I want true parallel multi-writer support!
I do agree, I don’t know why more people don’t just use Postgres. If I’m doing data exploration with lots of data (e.g., GIS, nD vectors), I’ll just spin up a Postgres.app on my macOS laptop, install what little I need, and it just works and is plenty fast for my needs. It’s a really great choice for a lot of domains. That being said, while I think Postgres is “the right tool for the job” in many cases, sometimes you…
See also, PGLite: https://pglite.dev/ And Turso: https://turso.tech/
Elixir + Postgres is the microservices killer...last time I saw VP try to convince a company with this stack to go microservices he was out in less than 6mo
This is the killer combo. Working on something now that uses pgmq + Elixir for DAG workflows: https://github.com/agoodway/pgflow
I'll take it one step further and say you should always ask yourself if the application or project even needs a beefy database like Postgres or if you can get by with using SQLite. For example, I've found a few self-hosted services that just overcomplicated their setup and deployment because they picked Postgres or MariaDB over SQLite, despite it being a much better self-contained solution.
I recently started digging into databases for the first time since college, and from a novice's perspective, postgres is absolutely magical. You can throw in 10M+ rows across twenty columns, spread over five tables, add some indices, and get sub-100ms queries for virtually anything you want. If something doesn't work, you just ask it for an analysis and immediately know what index to add or how to fix your query. It…
It's 20xx just use sqlite. Almost no-one needs all that power; they sure do think they do, but really don't. And will never. SQLite + Duck is all you need even with a million visitors; when you need failover and scaling you need more, but that is a tiny fraction of all companies.
Huh? SQLite is designed for application databases. Postgres is designed for client-server. It's not about "power" (what does that even mean?), it's about totally different design choices that are intended for different purposes. It's an architecture question, not a "power" or "visitors" question.
Would you except "Just use postgres for client-server" as a reasonable change?