3 ms·
As for Postgres, I chose Timescale because you can easily change it at any time for Postgres. I plan to have it as a managed service in the future, which means
by nevodavid10 3y ago
As for Postgres, I chose Timescale because you can easily change it at any time for Postgres.
I plan to have it as a managed service in the future, which means that it will hold a lot of clients - some big, some small.
But I think I should def make another smaller version without Kafka and Timescale.
- bee_rider 3y agoWhen it is a managed service, will a single individual be feeding into a single sort of taste profile over multiple sites? Actually am I crazy to thing that wouldn’t be the worst thing in the world? Tracking people across multiple sites without their informed consent is of course totally unethical spying, but if it is clear that they are consciously interacting with UI like yours and they know it is shared, that doesn’t seem so bad. (?) And it could be nice if Pandora would start suggesting soundtracks to movies I’ve upvoted on Amazon or something like that…
- badtuple 3y agoIt's hard enough to view the content I want to see when everyone has "smart" content feeds shoving ads in my face. I work hard to isolate what I look at on Amazon from what I see on YouTube so marketers don't ruin the little bits of the web I'm able to enjoy intentionally. Creating cross-site bleed of account information behind the scenes just makes everything worse for the user who can no longer drive your app...they just have to plop in and let it drive them. You handwaved the idea of consent by saying it's "clear" to the user. But if there isn't a way to opt out then consent isn't addressed at all.
- bastawhiz 3y agoEven if you were managing this for third parties, there's no reason to assume your scale would necessitate this complexity. One of my Postgres databases stores analytics data for podcasts. 800gb worth in two tables. It's just vanilla Postgres with indexes. P90 queries complete in 100ms. I serve >10k customers with one write instance and one read-only replica. Some podcasts get thousands of listens per second at peak times. Stripe relied entirely on Mongo for storage and queueing at a scale that you'll almost assuredly never reach. That's probably inadvisable today, but the point is that the more systems you have, the more systems you need to maintain and the more things that can break and the more places you'll eventually find bottlenecks.
- upon_drumhead 3y agoYou chose timescale because you can swap it out for Postgres? Why not start with Postgres then? Is there anything timescale provides that is beneficial over Postgres?