I've been using Elixir for the past 5-6 years for my startup. We use pg_notify extensively to broadcast changes between running nodes (basically, use Phoenix.PubSub locally in our apps, with a GenServer to subscribe+re-broadcast using pg_notify).
This has been a really elegant and low-complexity way to get distributed pubsub without the complexity of running a distributed erlang cluster (which seems a lil bit painful in a K8S+Continuous Deploy world)
There -are- some big downsides to be aware of though.
1. You can't use PgBouncer w/ LISTEN/NOTIFY. This has been really painful because of the high memory overhead of a pgsql connection + elixir keeping a pool of open pgsql connections. The tried and true method of scaling here is to just use PgBouncer. We've kicked the can on this by vastly over-provisioning our pg instance, but this has cost $10s of thousands on the cloud. Of course, it's solvable (dedicated non-pgbouncer connection pool just for LISTEN/NOTIFY, for example), but painful to unwind.
2. The payload has a fixed size limit (8KB, IIRC). This has bitten us a few times!
Even though I really like pg_notify, I think that if I were starting over, I'd probably just use Redis Pub/Sub to accomplish the same thing. Tad bit more complex if you're not already running Redis, but without the downsides. (Of course, w/ Redis, you don't get the elegance of firing a notification via a pg trigger)
I’ve been running my startup on Google Cloud for the past 5 years. Initially got around 100K credits for the first year and have been steady spending $5-10K/mo since - not huge spend, but not nothing either.
In the early days, quota increases felt like a formality - put in a request and they’d get approved a few minutes later. Sometimes it was a bit of a puzzle (you can’t increase X unless you also know to ask for Y) - but never a roadblock.
Over the past 2-3 years, I’ve starting having the experience of having a quota increase denied and having a helpful account manager insist we jump on a call to get the quota increase. I’m not talking about anything crazy either - like maybe going from an existing 72 vCPU quota to 144.
Doesn’t make me feel very confident that I’d actually be able to use the cloud to actually do cloudy things in a pinch, like bursty on-demand scaling
Tangential comment - but that Netezza appliance was really cool. I was able to use one early in my career, circa 2008. It had a nice cli query interface similar to psql (maybe it spoke postgres protocol, I don't remember) - and was blazing fast. I ran totally rookie-mistake filled, unoptimized queries on tables w/ billions of rows and got results back in ~seconds. Of course, not so impressive now, but was really impressive 15 years ago!
They had a really wild architecture with FPGAs that, if I remember correctly, sat in between the CPU/disk and was used to offload some of query execution.
It was wildly expensive + expensive to maintain, so the company ended up (unsuccessfully, I think) jumping to Hadoop. Crazy times :)
I really enjoy working with LiveView and have personally built several substantially sized apps with it.
One of my current frustrations is the inability, out-of-the-box, to write to sessions from LiveView. I understand the reason why, but I personally find the "redirect to a controller to set the cookie" pattern to be a bit hacky and more work than I'd like in order to just.. set a cookie.
I hope that a future release has a built-in pattern for writing sessions and cookies in general.
I made a similar jump over the past few years out of frustration with stagnating apple hardware (pre-m1). I spent a year with a hackintosh, which worked pretty well, but became disenchanted by the continued locking-down of the OS.
For the most part, daily driving Linux as my desktop has been great - no small thanks to Electron. Slack, Spotify, VSCode, etc. all just mostly work.
Going the arch-route took extra upfront work since you're effectively building a desktop environment from scratch, but the benefit is knowing exactly how -everything- works. If I press my "volume up" shortcut and the overlay volume bar isn't displayed, I know exactly which sway config and executable to look at. It's refreshingly simple.
The downsides are that upgrading is a bit anxiety producing (will I break anything?). HiDPI on Linux is still (in my experience) a bit of a mess. If you run wayland, you need to patch xwayland/sway/wlroots if you don't want blurry x11 apps. And there are some quirks- like, I can't drag files into Slack. Maybe it's fixable, but at some point you become satisfied with "good enough".
I work on a SaaS app in the healthcare space where IE11 is the preferred browser, and was getting worried watching all of our favorite tools begin to completely drop IE11 support (Tailwinds, Bootstrap) - effectively punishing us for the sins our customers IT orgs.
This brings me hope. But only a little. I’m sure they’ll find a way to keep running it.
As part of the 41% that recently swapped out their "gas guzzler" Porsche for a Tesla M3, I can confirm that they're ready for prime time.
The Tesla Supercharging experience has been pretty great. The route planner calculates charging stops automatically and you only need to wait 5-10 mins to top off ~100 miles before you're back on the road.
Without the Superchargers, though, the experience would be pretty terrible - how is the current charging station grid for non-Tesla EVs?
I use this daily with linux/i3 and it has been very pleasant! Installed it and it basically does exactly what you expect. Only issue was some conflicting default i3 shortcuts that conflicted, but were easy enough to remap
It’s been slim picking for 5K monitors- especially if you’re not on OSX where thunderbolt dispay output is much more complicated.
Besides the (now discontinued) Planar IX2790, which had severe quality control issues (went through 4- all with major dead pixels and burn-in), I don’t think there are any readily available DisplayPort-based 5K monitors out there :(
Feels like hidpi displays have pretty much stagnated outside of apple ecosystem
I’ve only looked at CrunchyData which does seem like more complexity than I want - I was willing to suck it up pay the premium but the monthly OOM crashes have forced my hand - but to where, I don’t know yet
To clarify, it’s a lot more work than bringing up a snapshot. You need to do a full export as SQL and reimport as SQL. Super annoying, slow, and requires hard downtime.
Am using SQL proxy but doesn’t do much re: HA.
I don’t know, I’ll probably just run my own Postgres at some point. The only peace of mind that I get from Cloud SQL is the automatic backups.
- No way to upgrade major postgres version without full export and import into new cluster.
- Incredible delay between postgres versions. IIRC, it took nearly 2 years for them to add postgres 11 after it was released.
- HA is basically useless. Costs double, still has 4-5 minute window of downtime as it fails over, doesn't avoid maintenance window downtime (both primary/standby have same maintenance window) and you can't use it as a read replica. Honestly, feels like a borderline scam since I'd imagine a new instance could be spun up in the same amount of time a failover takes (but I haven't tested)
- With default settings, we experience overly aggressive OOM-killer related crashes on a ~monthly basis during periods of high utilization. On a 32GB instance, OOM killer seems to kick in around 27-28GB and it's incredibly annoying.
- Markup over raw instances is almost 100%, with no sustained use discount outside of a yearly commit.
It's just a lot of money to pay for a crashy, outdated version of Postgres.
Yeah, have hugely over provisioned disks for IOPS. Am still using public ip + cloudsql-proxy because the alternative didn't exist when I first deployed, but I'll try switching.
I used to be a huge fan of GCP and bet on it to power my startup, and have come to greatly regret it.
Recently, I needed to increase a CPU-limit quota from a small number (like 16 vCPUs to 64 vCPUs) - nothing crazy. In the past, the quota increase system was more or less automated and would only take a few minutes to process.
This time, however, GCP denied my quota increase and forced me to schedule a call with a sales rep in order to process the quota increase. It was the biggest waste of time and kind of goes against the entire point of instant cloud resizing.
It also feels like the velocity of new features, instance types, etc has slowed down dramatically in the past year. Also, while I'm ranting, Google Cloud SQL is probably the worst cloud service I've ever used (and it costs an arm and a leg for the pleasure!)
This has been a really elegant and low-complexity way to get distributed pubsub without the complexity of running a distributed erlang cluster (which seems a lil bit painful in a K8S+Continuous Deploy world)
There -are- some big downsides to be aware of though.
1. You can't use PgBouncer w/ LISTEN/NOTIFY. This has been really painful because of the high memory overhead of a pgsql connection + elixir keeping a pool of open pgsql connections. The tried and true method of scaling here is to just use PgBouncer. We've kicked the can on this by vastly over-provisioning our pg instance, but this has cost $10s of thousands on the cloud. Of course, it's solvable (dedicated non-pgbouncer connection pool just for LISTEN/NOTIFY, for example), but painful to unwind.
2. The payload has a fixed size limit (8KB, IIRC). This has bitten us a few times!
Even though I really like pg_notify, I think that if I were starting over, I'd probably just use Redis Pub/Sub to accomplish the same thing. Tad bit more complex if you're not already running Redis, but without the downsides. (Of course, w/ Redis, you don't get the elegance of firing a notification via a pg trigger)