Pi-hole does have a feature where you can temporarily disable it for exceptional cases like that. You could have used that instead of uninstalling it altogether.
89 karma · joined February 1, 2014
Fwiw, I went down the path of trying to do something similar with Drizzle and gave up since it was in such a state of flux (this was last year). There are (were) a ton of edge cases around trying to add automatic filters to queries to the point that it was hard to justify not just rolling my own ORM.
- How does authz work? Can I use Postgres RLS? If not, how would you address row or column-level permissions in a system that uses this? - If you're using logical replication to sync with PG, is there a limit to the number of clients you can have connected? I see there is a lot of work around de-duping live queries, but how well does that work in practice? - Any thought to making an extension for Postgres? My main hesitation right now is that I have to go through an NPM package to use this but a lot of our tooling expects a plain Postgres connection. - REALLY looking forward to seeing how the schema migration story looks.
Overall, it seems to address most of the use-cases where I'd reach for an ORM or API server so I'm really interested to see where this could go.
I commit on the branch about as often as I did when writing code manually: before I'm about to do something big or try something that might break other things.
Some guys with AK-47s kept the world's most powerful military pretty busy for 20 years, so I wouldn't underestimate the value of a few rifles against authoritarianism.
I'd guess something else driving/piloting some kind of vehicle that isn't as saturated.
Like the other response, my concern would be reliability on a new service, but I’d use it after it was around for a year or two.
That said, do you plan do offer branching or any other features that Neon offer? I think that's their big selling point along with separate billing for compute and storage.
I mean, look, there's no one who wants to stop having to write code more than me. Our industry is full of make-work and pointless drudgery for no reason and I'd love to see that be made pointless by AI. But there's the old quote about overestimating the short term progress and underestimating the long term progress that applies here. Your version of "awhile" is probably pretty similar to the "awhile" of people excited about past technologies. As another comment pointed out, we engineers have been trying to automate ourselves out of a job for quite a while now and I don't see this being much different. I'm old enough to remember the 4GL fad and people were just as breathless then that you didn't need those pesky engineers anymore and soon you'd be able to do similar things as AI is promising. Low-code was a thing recently too. These things gradually chip away at the skills you need to make things happen, but something has to ultimately be responsible for the results and that's where humans come in.
> Separate filtering from retrieval
Why? What does this buy you? You're already doing stuff in the DB. Why make another round trip after the application layer has decided it needs more stuff? We did this everywhere in a previous iteration of the app I work on and it was terrible for performance. You might actually make the DB do more work here since it has to do double the queries (and connection overhead).
> Avoid performing operations on returned results
I guess this is the one valid point but honestly I haven't run into this much beyond some averages and summing (e.g. a balance is the sum of debits and credits). I'm okay with having those in the DB because they rarely change. What happens when someone wants to filter on one of these calculated values, though? Do you do that in the application layer too? How does Bob use his BI tool to get the data he needs from your application layer?
> Move joins into the application layer
Yep, ship all the data over the wire then write your own code to match them up. More code to maintain and possibly slower! Again, what is this buying you other than some handwavey, vague promise of "scalability"?
There are reasons not to put logic in the DB but I don't feel like these make a good argument. Someone will keep parroting these points, though, all in the name of made-up constraints (e.g. "must scale") that were never actually needed. After all, with the architecture he proposes your app will be bottlenecked on the DB either way so might as well move the point that it happens further back. It's a sample size of 1, but every project I've worked on has had positive performance benefits by moving computation closer to data rather than just adding computation. By doing that, we didn't have to "scale" until much later.
Does it make sense to put all of your logic in the DB? Probably not. Does it make sense to put some logic there? Maybe! Test, evaluate and have an exit plan if it doesn't work, but absolutely never, under any circumstances listen to absolutes like this article.
Immutability and bitemporal querying are nice features in Datomic, but the trade offs for most teams are an unfamiliar query language, unfamiliar runtime/hosting requirements, unknown performance footguns, little if any integration with 3rd party tools, and (until recently) licensing costs. If it were me, I'd probably deal with the headache or complexity of adding triggers/permissions and audit tables to Postgres to get that functionality if all of those other things are solved instead.