241–250 of 270 posts
Earlier quoted context omitted.
I developed and use(d) pgxplorer (github.com/pgxplorer). So, I can tell you this: the best out there is psql (CLI). There exists no use case where a GUI is better than psql.
Not even diagramming relationships between tables?
Earlier quoted context omitted.
> Love for static typing is basically Stockholm's syndrome Funny, that's sort of how I feel about my (long) time "loving" dynamic typing. Now I find it is such a relief to validate data once on the way in and completely trust it to be what it says it is thereafter. I found dynamic types required more bureaucracy (if I wanted to sleep at night) in the form of unit tests and precondition checks everywhere. YMMV I suppo…
> I found dynamic types required more bureaucracy (if I wanted to sleep at night) in the form of unit tests and precondition checks everywhere. This merits clarification Most of programming in dynamic typing should be implicitly statically typed. Know what you're passing. Obey the implicit (duck-typed) interfaces Basically, don't just check "if it's a list do that, if it's one element do something else, if it's a num…
Yeah, I thought that too. After years of persistently seeing stupid (sometimes critical) bugs due to assuming the correct thing was being passed, I concluded that 1. the only sane thing to do is add explicit precondition checks that raise meaningful exceptions when assumptions are broken, and make sure those paths are exercised by unit tests, and that 2. I would much rather have that done statically and automatically by a compiler.
> Basically, don't just check "if it's a list do that, if it's one element do something else, if it's a number do another thing" - this is a beginner's mistake (and I did those)
I think this may be a misunderstanding of what I meant by "precondition checks" - I meant explicitly checking the assumptions being made by a method, most of which are type checks (foo.kind_of?) or (more commonly) interface checks (foo.respond_to?).
> Though it's not so much static typing that sucks, it's its implementation in the Java/C++ way. Go and Rust make it better.
I don't have much problem with Java's implementation of static typing at all, and I don't think C++'s problem is its static typing implementation. I find Go's implementation a bit inflexible and hard to work with though.
Again, YMMV!
Earlier quoted context omitted.
As for the clustering in general... Scalability may be not important, but replication and failover should be. I believe, every place that had existed long enough must've had theirs "ouch, our master DB host went down" moment. I wasn't able to set it up properly some years ago and settled down with warm standby replica (streaming + WAL shipping) and manual failover. Automating it (and even automating the recovery when…
You can try http://repmgr.org/ for automation. It offers easy commands to perform failover and even has an option to configure automatic one. After reading about github issues[1], I am a bit cautious about having automatic failover though. [1] https://github.com/blog/1261-github-availability-this-week
As for automation... Things can always go wrong, sure. But I wonder how many times HA and automatic failover had saved the day at GitHub so no outside observers had a faintest idea there was something failing in there.
Earlier quoted context omitted.
As for the clustering in general... Scalability may be not important, but replication and failover should be. I believe, every place that had existed long enough must've had theirs "ouch, our master DB host went down" moment. I wasn't able to set it up properly some years ago and settled down with warm standby replica (streaming + WAL shipping) and manual failover. Automating it (and even automating the recovery when…
> you start a fresh server, tell it some other server address to peer with, and it does the magic This is the one thing I ask of every database software, yet we still don't really have it. 90% of problems could be solved if there was a focus on the basics like easy startup, config and clustering.
Thanks to the RethinkDB team and Slava for everything they've done over the years, and for making RethinkDB open source, I continue to use it in my projects.
While it might have ultimately lead to your demise, thank you for valuing correctness, simplicity, and consistency. I've never seen another document story company get things so right.
Hey all, author here. FYI, the post is still in its unpublished state. It's basically right, but I've been meaning to edit it for tone and rewrite the market failure section for clarity. Didn't get the chance to do that before it made it on HN, so keep in mind that you're reading a (late) draft.
As a former startup founder, I totally empathize - it's always clearer with hindsight but it's important to honestly reflect so you can apply the lessons learned to the next turn of the ferris wheel. > We set out to build a good database system, but users wanted a good way to do X. If you replace "database system" with "[any product]," it encapsulates the reason why many startups fail. I was guilty of it too. I think…
There's a very closely related form that is common for non-technical founders which is "We're going to use technology to fix ____ industry"
A founder with experience in a particular industry may see how inefficient it is, and how much scope there is for improvement based on technological solutions, but business live-an-die by the question: "Are there enough people who will pay us to solve this problem for them?"
Superficially, it seems like "I can make your business run more efficiently" is a reasonable approximation for "I have something that you will pay money for", but it has a very similar value-gap to "I can provide you with a technically better database".
"More efficient" and "technically better" are both things that ought to be valuable to customers, but often aren't valuable enough to get them to hand over their money.
Earlier quoted context omitted.
Intellectual is the wrong target, just as much as easy. Humans have a limited capacity to understand complex systems, and once they grow to a certan point, your ability to integrate and innovate on them is limited due to overhead of the layers of incedental complexity. Easy is just shoving complexity under the rug. Simplicity, and building systems meant for our meager human intelligences is better. I am not terribly…
The thing is, the modern systems are often less complex. SQL databases are generally far simpler than MongoDB - you just need to learn relational algebra rather than blindly shoveling whatever JSON you got into the DB. As for Java + async + threads, I use Akka and it's basically seamless. But Netty + core Java Executors is fine too, just more verbose.
I don't know, my personal opinion was that RethinkDB had its head on straight, MongoDB is garbage and still neither is so much better than PostgreSQL that I will switch away from it. Postgres is the default datastore (because schemas are awesome) for me, and I haven't had a use case yet where I needed something that Postgres wouldn't do. Maybe if you have a very specific need, you'd reach for another datastore (come…
That's been my experience as well. Postgres handles everything until you hit an edge case on some of your data (volume writes with scale out, performance critical advanced functionality, heavy BI work with huge datasets, etc). When you hit those edge cases or specific needs, you implement the specialty solution. Most people never come close to those edge cases though. When they do, PGs foreign data wrappers make the…
Because of single threaded query execution, lack of MPP, or something else?
Fascinating read, albeit a sad one: I love RethinkDB, and use it personally every day in our particular production deployment.[1] But -- and to Slava's point -- we didn't/don't/wouldn't pay for it, and in that regard, we were part of the problem. That said, the constraint on that particular problem was that it had to be open source, and if it couldn't have been RethinkDB, it would have been some other open source dat…
Having a popular OSS project helps me a bit when getting job opportunities but that's all... Even if you considered me as a single-person team and counted 'better job opportunities' as a return on my investment, I don't think the increased salary even comes close to getting me a ROI on time spent.
OSS is a terrible investment. It's like buying a lottery ticket.