umur

As a side note, and to pg's point, Microsoft did make some very smart Web 2.0 acquisitions from Silicon Valley in the years since --most notably LinkedIn and Github--, and let them run relatively independently.

> So if they wanted to be a contender again, this is how they could do it: Buy all the good "Web 2.0" startups. They could get substantially all of them for less than they'd have to pay for Facebook.

>Put them all in a building in Silicon Valley, surrounded by lead shielding to protect them from any contact with Redmond.

Thank you Paolo — for what was an excellent post, and also for this helpful update!

There is indeed a large gap in the market between outsourcing all your infrastructure to Hyperscalers vs. hosting it on DIY-bare-metal and/or VPC providers. An open source alternative to AWS would do much to fill that gap, and we are building just that at Ubicloud (I'm one of the co-founders).

So far with Ubicloud, you get virtual machines, load balancers, private networking, managed PostgreSQL, all with encryption at rest and in-transit. The Ubicloud managed service uses Hetzner bare metal as one of its hosting providers, which cuts costs 2x - 10x compared to AWS/Azure. Would love to hear any feedback if you'd like to give it a try, or go through the repo here: https://github.com/ubicloud/ubicloud

Our naming intent is for a "ubiquitous" cloud, one that can run anywhere -- no affliations! :)

Ubicloud cofounder here, thanks for the question!

You can think of Ubicloud as software that takes bare metal servers as its input, and provides VMs and other cloud infrastructure services as its output. You can self-host Ubicloud on your own hardware, or use it as a managed service.

Comments below are on point: Compared to OpenStack, Ubicloud is simpler, comes with a managed service that you can use in minutes (vs days/weeks), and provides more services such as managed databases.

Compared to Kubernetes, Ubicloud covers layers both above and below Kubernetes. For example, running K8s on AWS/Azure/GCP depends on having VMs where the pods can run on. Similarly, running a managed database service on K8s requires much more than the basic K8s service itself.

Put differently, all major cloud providers have proprietary software similar in purpose to Ubicloud, which they use to provide their core cloud services. Using AWS as an example, services like EC2, RDS for managed Postgres, or EKS for managed Kubernetes, all run on this type of software. Ubicloud makes this software open source, and allows it to run anywhere--not just on AWS data centers.

Much appreciate the nits! I've made a few minor tweaks right now, we will do a more complete revision later on.

Thank you for your feedback! I've just made several edits to the text for clarity; will also fix UX bugs and do bigger a update in the upcoming weeks.

thank you and that's correct, just updated the docs as well.

Ubicloud cofounder here.

Thanks and yes, the magnitude of it was surprising to us, and that for a common use-case. The default runners you get for Github Actions if you are compiling ARM code is x86, which uses qemu emulation. That default is 10x slower vs native ARM.

Combined also with 10x higher prices, a 100x price-perf gain vs the default was unusual.

Happy to hear your suggestions, of course, will ping you through your HN profile

That’s great to hear, thank you! Please feel free to email us if you have questions. For pricing, the first link is for VMs, and the second is for managed database instances, which also have 5x more disk. You’re right in that we should aggregate and better present our pricing.

Thank you! Quick notes: - Resizing instances after provisioning is a manual operation for now. We'd use the same backup machinery that exists to automate it; until then you could do it manually or we're happy to help through a support request.

- Yes, you can create multiple databases per instance.

- We don't support pgvector yet; initial extensions we have are those in contrib, with more to come.

- Going through a VM to fetch the data from/send data to file store is the most common

- We take backups automatically, with point-in-time-recovery available to the minute. We also allow you to "fork" a database using a similar approach: i.e. your database remains intact; you just add a new database to it from a past point in time (typically useful for dev, test and/or analytics)

Congrats Mitchell! Thanks for all your great work, and best of luck for what's ahead.

We also have a talk that one of our core team members gave earlier today at PGConf.EU that goes through some of the inner workings of our managed service. Its video is not posted yet given it's been just several hours, but should be available here once ready:

https://www.postgresql.eu/events/pgconfeu2023/schedule/sessi...

Right now, we have an early block store (EBS) that is non-replicated, and that we are testing and using internally. Over time, we will expose it as a service as well. But object store (S3) will come first.

Thank you, fixed the broken link!

Yes, ack on both. We already do point-in-time-restore your database with 1-minute granularity. And the docs are thin currently; we will add more to them.

We're using the same core control plane approach that still powers multiple PostgreSQL services like Heroku Postgres, Citus/Azure Cosmos DB for PostgreSQL and Crunchy Bridge. Ubicloud is being built by core members of the same teams that built those products, improved with learnings. We are yet in preview and not as feature complete, but we will continue adding more features, building them in the open.

Yes, exactly, our object store is in the works.

And thank you, we are hiring. Could you send your CV to imagine at ubicloud dot com?

Ah, I see. The key part above is "to third parties". If you're using ubicloud to provide a managed/hosted service for yourself, or your company, that's wonderful. You could even be a massive organization and do that. It's just that you are not providing the managed service to other parties such as your customers - essentially, that you're not a hosting provider re-selling the software.

It means that our source code is open and transparent to all of our users. You can use it for free, modify it, or even re-distribute it - the main restriction is that you are not offering it as a managed service to third parties.

If you have a particular use-case in mind that you need but feel is limited, please let us know. Happy to talk through it and see how we can help.

(author of the post here)

Thank you, and yes, we will be in the US in the next few months.

(Part 3/3 - please see two comments below as the starting point) Aside from the different use-cases they address, there is one other, important difference between Citus and Redshift (and any other distributed database in the world, for that matter). Citus does not fork the underlying database, PostgreSQL. Instead, Citus extends PostgreSQL to transform it into a parallel processing, distributed database. We use PostgreSQL's powerful extension APIs to accomplish this (you simply CREATE EXTENSION Citus on PostgreSQL's latest version, 9.5, to get your distributed PostgreSQL database).

While this might appear as an implementation piece at first, it has important product implications, and might even impact how you might want to think about your database stack. By not forking the core database, you are choosing to always stay with the core PostgreSQL product. For starters, you get the uber-cool (and uber-fast) JSONB type that came with 9.4, or the recently checked in UPSERTs, or the popular PostGIS extension for geospatial capabilities. More philosophically, the moment you use forks of database, you know you'll be diverging over time. And when you introduce new databases and/or piece together many different ones to build one application, your development cycles will only get costlier and more complex over time.

This was a long answer to a short question, but hopefully useful. Let me know if you have questions, or any feedback using Citus – would love to hear your thoughts!

(Part 2) Now comes the storage engine, and cstore_fdw as it relates to PostgreSQL. Built by the Citus Data team, cstore_fdw is entirely a separate component from the Citus product above. It enables columnar storage for your vanilla, single-node PostgreSQL to provide data compression for faster analytics. As such, cstore_fdw does not come with any of the parallelism I've described above that Citus (or Redshift, Vertica etc.) provides.

Precisely because cstore_fdw is built for PostgreSQL, and Citus is PostgreSQL (see Part 3), however, you can still choose to use cstore_fdw as the storage engine for your Citus cluster. Citus will still parallelize the queries as you'd expect it to, but instead of hitting row- based tables, they will hit columnar ones. cstore_fdw has certain limitations, importantly it is not updatable; so we don't consider it as an alternative to a data warehouse. Rather, it is useful if you are archiving your quickly growing timeseries / event data on PostgreSQL or Citus.

Umur from Citus here. For purposes of this question, I’ll bucket traditional data warehousing (DWH) solutions like Redshift, Vertica, Greenplum together, although there are many nuances among each of them of course.

First, Citus is not a traditional data warehouse. We position Citus as the real-time, scalable database that serves your application under a mix of high- concurrency short requests and ad-hoc SQL analytics (i.e. think both random and sequential scans for a customer-facing analytics app). The default storage engine for Citus is the PostgreSQL storage engine, which is row-based. This is in contrast to many data warehouses, which often use a column store and/or batch data loads, and are focused purely on analytics. The trade-offs you get are: - Citus vs. DWH performance: DWH and Citus both have a similar parallelization for analytics queries (multi-core, multi-machine), but most data warehouses typically use a columnar storage engine instead of a row-based one. Columnar storage is designed for faster analytics queries, so that makes columnar DWH generally faster on longer running analytics queries. However, this comes at the expense of (1) concurrency and (2) short-request performance (think simple lookups, updates, real-time data ingest) vs. Citus' row-based storage. If you've tried having 10s of concurrent connections to Redshift for short lookups, or performing 100s/1000s of inserts/updates to power your application, these limitations will be familiar. This is to be expected, as Redshift is not designed as a real-time operational database, but an offline data warehouse.

In essence, the two classes of products are more complimentary than substitutes, even while they have some overlaps in their analytic capabilities. Something like Redshift will give you fast offline analytics, after you move your data in batch (via S3); Citus will directly power your analytic apps in real-time; without ETL'ing your event/user data back and forth between separate OLTP and OLAP databases. Both can be extremely fast: Redshift can run complex data warehousing queries that take an hour in a few minutes, Citus can scan and aggregate 100 million records in a few seconds, while simultaneously ingesting your events in real-time.

I hope that provides some clarification on the workloads. There is a lot more, including columnar storage and product approach (re: implications of extending Postgres 9.5 vs. forking Postgres 8.x), and I’ll dive into those in separate comments as well.

Umur from Citus here. Adding to Craig's comments:

Several things have changed over the last two years that allowed us to make this happen: Most importantly, we've continued building out the product for a more broad user base, grown with more customers and users, received further funding as validation, and expanded both our team and product to offer additional revenue generating services. All put together, open sourcing Citus is something we've always wanted to do, and we are excited to continue building on it for many years to come, with the help of the community and our enterprise customers.

Umur from Citus here. Our goal is to make CitusDB an enabler for your growth by making scaling out simple for you and your dev, ops and analyst teams. If we've made it a tax instead and haven't saved you significant time, effort and complexity in the process, we're not doing our job.

At a practical level, we offer several ways to accomplish this: - We provide free, open-source extensions on standard PostgreSQL (pg_shard, cstore_fdw) - We provide a free community edition of CitusDB for added functionality (e.g. massively parallel analytic queries, distributed joins) - For enterprises, we provide a sitewide, unlimited license of CitusDB Enterprise. For smaller projects there, we provide support and a per-node license. - For start-ups, we provide a flat rate of CitusDB Enterprise irrespective of your data volume.

The right approach depends on the company and the use-case. Either way, and given the quick time-to-deployment, any of the approaches should end up as a major cost saver.

three-fiddy it is! (Umur from Citus here)

I hear you, and we are working on fixing that even as it might take some time. The challenge for us is that for an enterprise, alternatives could cost literally in the millions (see Oracle pricing at $100k's for just a single 8-core commodity machine). For start-ups, we have offered Citus for prices lower than $5k per node in the past, and we provide an entirely free community version as well.

Essentially, our take is to not have pricing be what stops you from using CitusDB. And if you are an enterprise, the value you get from using Citus should far exceed that you'd get from any other alternative out there.

(disclosure: I'm one of the founders at Citus Data)

hey, one way to do that is to use the MongoDB foreign data wrapper - also mentioned in some of the earlier threads.

mongo_fdw (https://github.com/citusdata/mongo_fdw) allows you to run SQL on MongoDB on a single node. Citus Data allows you to parallelize your SQL queries across multiple nodes (in this case, multiple MongoDB instances) by just syncing shard metadata. So you would effectively run SQL on a sharded mongo cluster without moving the data anywhere else.

another idea could be to use MoSQL to neatly replicate each mongo instance to a separate PostgreSQL instance, and then use Citus Data to run distributed SQL queries across the resulting PostgreSQL cluster.

To me, the visa story shows just how resilient Eren has been in the face of failing external factors -- in this case, the immigration system. Udemy has a lot going for it.