ruslan_talpa

Give me access to your PG with a user that has no privileges, can not run queries longer then X ms and see how easy it would be to DOS the db :)

Soon (in the works now, it will be particularly interesting in the context of cloudflare workers talking to planetscale)

https://github.com/subzerocloud/showcase

Because queries like this will kill any db, and you don’t need any privileges

SELECT crypt( encode(digest(gen_random_bytes(1024), 'sha512'), 'base64'), gen_salt('bf', 20) )FROM generate_series(1, 1000000)

More explanations here https://www.freecodecamp.org/news/stop-calling-postgrest-mag...

Such a thing exists

https://github.com/subzerocloud/showcase/tree/main/cloudflar...

Been feeling lately the fatigue of managing 3-5 different services for a every single trivial project. This pushed me to explore adding SQLite support in my product [1], i think I'll wrap a Litestream [2] process in the same container and call it "Backed in a Box" :)

[1] https://github.com/subzerocloud/blue-steel

[2] https://github.com/benbjohnson/litestream

edit: typo

You can query and write to SQLite over http with [1] (i wrote it) but it's not through the method you describe (range for files).

https://github.com/subzerocloud/blue-steel

Hey @todsacerdoti thanks for posting this :) did you try it out? I think the repo did not yet have the actual rust code (which it does now)

And even the frontend is probably already written for the use-case that you have https://github.com/priyank-purohit/PostGUI

“ A React web application to query and share any PostgreSQL database”

And you can have the postgrest api up and running with https://subzero.cloud/ you just bring your own db that you control

I have a proof of concept for that :) (the db is PostgreSQL of course)

fargate with 0.25 vcpu 1gb m (lowest option) is ~$10/m ((0.01012 + 0.004445) * 24 * 30), article states it's $3 which is wrong + $16 ALB (that you need with fargate) that is $26/m for the lowest option.

You can setup a view (accessed by postgrest) that returns an error when there are no (correct) filters in the query so that takes care of select *... problem (also you can have the same logic in the proxy (nginx) layer

A “ton” is very relative. Those tables still have to be written even with ORM. And as for views/rls/triggers the total LOC i would say is orders of magnitude smaller then in traditional stacks and a lot more readable (it’s static definitions vs imperative code)

This is the “corect” response to the question above. :)

The things you said are a pain (or can’t be done) here is how you do it https://github.com/subzerocloud/postgrest-starter-kit

Specifically, testing the sql side with sql (pgtap) and having your sql code in files that get autoloaded to your dev db when saved. Migrations are autogenerated* with apgdiff and managed with sqitch. The process has it’s rough edges but it makes developing with this kind of stack much easier

* you still have to review the generated migration file and make small adjustments but it allows you to work with many entities at a time in your schema without having to remember to reflect the change in a specific migration file

I’ve heard the same type of argument a long time ago against choosing wordpress when it was still relatively new (usually from custom webdev shops when talking to clients)

You keep talking about db views as though you can only read from them (an not write to them) :)

It works for me (focus)

Although part of a bigger stack, this can be used independently for postgresql

https://docs.subzero.cloud/managing-migrations/

Internally it uses sqitch and apgdiff.

The process is almost exactly like the one you described for your tool.

Postgrest? :)

You can submit this link as a PR to this page https://github.com/PostgREST/postgrest-docs/blob/v6.0/ecosys...

is there a github repo with all this sample code?

> no one can fix

Really? No one? I learned haskell (my first FP lang) and rewrote the core of PostgREST (in my spare time) in about 6m... so stop scaring people :)

you CAN track the latest "CREATE" statement and deploy to a real system. Conceptually you only need to do a "diff" between your current "CREATE" and the on in the system where you are deploying. https://github.com/djrobstep/migra

Also something similar which uses apgdiff https://github.com/subzerocloud/subzero-cli

If you think RDBMs can't horizontally scale you have not kept up with the developments :) Look into https://docs.citusdata.com/en/v8.3/get_started/what_is_citus...

not exactly what i meant.

it's true that it's not a polished workflow to debug stored procedures because you you have to jump from your editor to pgadmin but i don't think this is such a big deal for two reasons.

- postgrest architecture is such that you rarely need stored procedures (not just me, all the projects), it's the exact same way ppl use databases without them (they just send queries to the db, same here). 90% of the code in this type of project is table/view definitions (with constraints) and appropriate grant/rls statements. So there is very little imperative code to debug.

- The type of stored procedures used is quite simple, isolated and mostly self contained, a single function, maybe calling some other helper functions (you are always 2 levels deep at most) so it's not like in other envs where you have to follow the code jumps between hundreds of functions and classes.

it is hard to read if you don't have some knowledge of haskell indeed and the comments part is true but it's not any harder then folowing other codebases if you don't know the particular language so i don't think this is a strong argument.

Another point is - it's not a library and you are not the one maintaining it :) the same way you are not maintaining, but still using things like postgresql,nginx,redis, rabbitmq.

I bet it's a lot easier to learn haskell and patch postgrest then to know C for 10 years and patch postgresql :)

why would you "expect" that if you don't know about it?

you are confusing postgrest with postgraphile :)

How do you easely piece together a (poerfull) rest api just by having the definitions of the tables in the database?

Very very old videos but you can get the core idea https://begriffs.com/posts/2014-12-30-intro-to-postgrest.htm...

https://begriffs.com/posts/2016-03-20-postgrest-tour.html