Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conduct background research the types of problems customers are trying to address with ReadReplicas #381

Open
pburkholder opened this issue Oct 15, 2024 · 1 comment

Comments

@pburkholder
Copy link
Contributor

No description provided.

@pburkholder
Copy link
Contributor Author

pburkholder commented Oct 15, 2024

@jadudm and I chatted on 2024-10-10 on the use of various DB tools on another TTS project.

He noted that when you expose a DB over an API, people will want to D/L the entire database, so be prepared for that.

They've been using PostgREST successfully, but have paired with it SlingData to make copies of useful data from the canonical database to another database for read access. This allows for better data partitioning, and you can also move a lot of SQL query logic from the application side, to the Sling YAML configuration, which is highly readable and maintainable.

This has a real upside compared to a ReadReplica, since Sling could de-identify PII and reduce exposure errors downstream.

It can also write to filesystems and S3, and to different formats (excel?, CSV). Also - SQLite is pretty awesome.

The use of postgREST with API keys has been working out well. Excel can read directly from an API, for example.

The TTS project has ~5Gb of data and the largest tables has 5M rows.

The pREST should also be considered as an alternative to PostgREST.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant