11–20 of 136 posts
Can Supabase author a set of Kubernetes manifests similar to what they run in production, and perhaps distribute those?
The options for spinning up CRUD apps (ie, 95% of projects) are still quite miserable.
There’s an initial learning curve with the row level security stuff, but once you get a good grasp of it and come up with a few patterns that suit your needs it’s insanely fast to develop on. You’re trading the time it takes to build and manage an api for the time it takes to setup RLS.
Even though it looks like a great product initially, it has a lot or errors and bugs when you are trying to actually build something more robust than a toy app.
Local development is a massive pain with random bugs.
The response time of the database also varies all over the place.
But the most important problem that we faced, was having so much of application logic in the database.
Row level security is their "foundational piece", but there is a reason why we moved away from database functions and application logic in database over a decade ago: that stuff in unmaintainable.
There is also really poor support and at the end of the day, the whole platform felt like a hack.
I think now, for most apps with up to 500_000 users (with 10_000 concurrent realtime connections) PocketBase is the best PaaS out there having tested a bunch of them.
A single deployable binary which PocketBase provides is a breath of fresh air.
Anything more than that, just directly being on top of bare metal or AWS / GCP is much better.
Personally, I had a really easy time getting Supabase to work locally. However, we use `dbmate` to manage our migrations instead of built-in Supabase migrations. Also curious to hear from others on this: > After a bit of sleuthing, it ended up that Supabase was taking a database backup that took the database fully offline every night, at midnight. This seems like a terrible design decision if true. Why not just backu…
the Val Town team were kind enough to share this article with me before they released it. Perhaps you know from previous HN threads that we take customer feedback very seriously. Hearing feedback like this is hard. Clearly the team at Val Town wanted Supabase to be great and we didn’t meet their expectations. For me personally, that hurts. A few quick comments
1. Modifying the database in production: I’ve published a doc on Maturity Models[0]. Hopefully this makes it clear that developers should be using Migrations once their project is live (not using the Dashboard to modify their database live). It also highlights the options for managing dev/local environments. This is just a start. We’re building Preview Databases into the native workflow so that developers don’t need to think about this.
2. Designing for Supabase: Our goal is to make all of Postgres easy, not obligatory. I’ve added a paragraph[1] in the first page in our Docs highlighting that it’s not always a good idea to go all-in on Postgres. We’ll add examples to our docs with “traditional” approaches like Node + Supabase, Rails + Supabase, etc. There are a lot of companies using this approach already, but our docs are overly focused on “the Supabase way” of doing things. There shouldn’t be a reason to switch from Supabase to any other Postgres provider if you want “plain Postgres”.
3. That said, we also want to continue making “all of Postgres” easy to use. We’re committed to building an amazing CLI experience. Like any tech, we’re going to need a few iterations. W’re building tooling for debugging and observability. We have index advisors coming[2]. We recently added Open Telemetry to Logflare[3] and added logging for local development[4]. We’re making platform usage incredibly clear[5]. We aim to make your database indestructible - we care about resilience as much as experience and we’ll make sure we highlight that in future product announcements.
I’ll finish with something that I think we did well: migrating away from Supabase was easy for Val Town, because it’s just Postgres. This is one of our core principles, “everything is portable” (https://supabase.com/docs/guides/getting-started/architectur...). Portability forces us compete on experience. We aim to be the best Postgres hosting service in the world, and we’ll continue to focus on that goal even if we’re not there yet.
[0] Maturity models: https://supabase.com/docs/guides/platform/maturity-model
[1] Choose your comfort level: https://supabase.com/docs/guides/getting-started/architectur...
[2] Index advisor: https://database.dev/olirice/index_advisor
[3] Open Telemetry: https://github.com/Logflare/logflare/pull/1466
[4] Local logging: https://supabase.com/blog/supabase-logs-self-hosted
[5] Usage: https://twitter.com/kiwicopple/status/1658683758718124032?s=...
Curious why have you decided for Drizzle over Kysely. I was recently exploring the space, and Kysely came on top as a framework with broader adoption. https://npmtrends.com/drizzle-orm-vs-kysely
Curious why have you decided for Drizzle over Kysely. I was recently exploring the space, and Kysely came on top as a framework with broader adoption. https://npmtrends.com/drizzle-orm-vs-kysely
Kysely is a little more established than Drizzle, which I think is one of the major reason why it has broader adoption. My bet is that Drizzle is moving really fast, gaining adoption, and might catch up at some point. It's also - in terms of performance - super fast, and nicely layers on top of fast database clients.
Some of the differences that I liked about Drizzle were the extra database drivers being core and developed as part of the main project. It supports prepared statements, which is awesome. The Drizzle API also covers an impressive percentage of what you can do in raw SQL, and when there's something missing, like a special column type, it's been pretty straightforward to add.
I prefer the way that it lets us write parts of queries, and compose them - like you import expressions like "and" and "eq" and you can write and(eq(users.id, 'x'), eq(users.name, 'Tom')) and you can actually stringify that to the SQL it generates. Or you can do a custom bit of SQL and use the names of table columns in that, like `COUNT(${users.name})`. I can't say scientifically that this is superior, and it's almost a little weird, but I've really found it a nice way to compose and debug queries.
That said, Kysely is also a great project and it'd be possible to build great products with it, too. I just found the momentum, API, and philosophy of Drizzle to be pretty compelling.
I also had the same experience with Supabase. Even though it looks like a great product initially, it has a lot or errors and bugs when you are trying to actually build something more robust than a toy app. Local development is a massive pain with random bugs. The response time of the database also varies all over the place. But the most important problem that we faced, was having so much of application logic in the…
Personally, I had a really easy time getting Supabase to work locally. However, we use `dbmate` to manage our migrations instead of built-in Supabase migrations. Also curious to hear from others on this: > After a bit of sleuthing, it ended up that Supabase was taking a database backup that took the database fully offline every night, at midnight. This seems like a terrible design decision if true. Why not just backu…
Supabase daily backups just use pg_dump. If their database was going offline, then something else was broken.
To give context, Val Town have a particularly write-heavy setup, storing a lot of json strings. The nightly backups were causing write-contention, even at their relatively small size. We didn’t detect errors because they were application-level. We should have moved them to PITR as soon as they mentioned it since the timing was so obviously coinciding with backups. We’re investigating moving everyone to PITR (including the free tier). At the very least, we’ll add more control for backups - allowing users to change the maintenance window, or possibly disabling backups completely if they are managing it themselves.
The options for spinning up CRUD apps (ie, 95% of projects) are still quite miserable.
Mostly that solves setting up Auth and Prisma SQL ORM to your DB, but Next.js App directory with the Prisma setup (2 files / 50 LOC) done is even smoother.