HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
citusdata
citus
C2016–2025
citusdata / citus

citus

Distributed PostgreSQL as an extension

36Distinct people
54Mentions
1Explicit recommenders
12.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Distributed PostgreSQL as an extension

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

(Ozgun from Citus Data) Your observations on cstore_fdw are accurate. I'm adding a few points about our learnings from cstore deployments in production. From a use-case…

ozgune used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:02:05 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year54 dated mentions

Observed mentions: 2016-03-24 15:56:44 UTC to 2025-09-22 20:41:53 UTC.

0369122016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 11 mentions; 1 submissions, 10 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 7 mentions; 3 submissions, 4 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC707
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC11110
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC110
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC606
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC734
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC615
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC817
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC303

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
The Citus database is 100% open source. Learn what's new in the Citus 14 release blog and the Citus Updates page. What is Citus? Citus is a PostgreSQL extension that transforms Postgres into a distributed database—so you can achieve high performance at any scale. With Citus, you extend your PostgreSQL database with new superpowers: Distributed tables are sharded across a cluster of PostgreSQL nodes to combine their CPU, memory, storage and I/O capacity. Reference tables are replicated to all nodes for joins and foreign keys from distributed tables and to maximize read performance. Distributed query engine routes and parallelizes SELECT, DML, and other operations on distributed tables across the cluster. Columnar storage compresses data, speeds up scans, and supports fast projections, both on regular and distributed tables. Query from any node enables you to utilize the full capacity of your cluster for distributed queries You can use these Citus superpowers to make your Postgres database scale-out ready on a single Citus node. Or you can build a large cluster capable of handling high transaction throughputs, especially in multi-tenant apps, run fast analytical queries, and process large amounts of time series or IoT data for real-time analytics. When your data size and volume grow, you can easily add more worker nodes to the cluster and rebalance the shards. Our SIGMOD '21 paper Citus: Distributed PostgreSQL for Data-Intensive Applications gives a more detailed look into what Citus is, how it works, and why it works that way. Since Citus is an extension to Postgres, you can use Citus with the latest Postgres versions. And Citus works seamlessly with the PostgreSQL tools and extensions you are already familiar with. Why Citus? Getting Started Using Citus Schema-based sharding Setting up with High Availability Documentation Architecture When to Use Citus Need Help? Contributing Stay Connected Why Citus? Developers choose Citus for two reasons: Your application is outgrowing a single PostgreSQL node If the size and volume of your data increases over time, you may start seeing any number of performance and scalability problems on a single PostgreSQL node. For example: High CPU utilization and I/O wait times slow down your queries, SQL queries return out of memory errors, autovacuum cannot keep up and increases table bloat, etc. With Citus you can distribute and optionally compress your tables to always have enough memory, CPU, and I/O capacity to achieve high performance at scale. The distributed query engine can efficiently route transactions across the cluster, while parallelizing analytical queries and batch operations across all cores. Moreover, you can still use the PostgreSQL features and tools you know and love. PostgreSQL can do things other systems can’t There are many data processing systems that are built to scale out, but few have as many powerful capabilities as PostgreSQL, including: Advanced joins and subqueries, user-defined functions, update/delete/upsert, constraints and foreign keys, powerful extensions (e.g. PostGIS, HyperLogLog), many types of indexes, time-partitioning, and sophisticated JSON support. Citus makes PostgreSQL’s most powerful capabilities work at any scale, allowing you to handle complex data-intensive workloads on a single database system. Getting Started The quickest way to get started with Citus is to use the Elastic Clusters in Azure Database for PostgreSQL Flexible Server managed service in the cloud—or set up Citus locally. Citus Managed Service on Azure You can get a fully-managed Citus cluster in minutes through Elastic Clusters in Azure Database for PostgreSQL Flexible Server. Azure will manage your backups, high availability through auto-failover, software updates, monitoring, and more for all of your servers. To get started with Citus on Azure, use the Elastic Cluster quickstart. Running Citus using Docker The smallest possible Citus cluster is a single PostgreSQL node with the Citus extension, which means you can try out Citus by running a single Docker container. # run PostgreSQL with Citus on port 5500 docker run -d --name citus -p 5500:5432 -e POSTGRES_PASSWORD=mypassword citusdata/citus # connect using psql within the Docker container docker exec -it citus psql -U postgres # or, connect using local psql psql -U postgres -d postgres -h localhost -p 5500 Install Citus locally If you already have a local PostgreSQL installation, the easiest way to install Citus is to use our packaging repo Install packages on Ubuntu / Debian: curl https://install.citusdata.com/community/deb.sh | sudo bash sudo apt-get -y install postgresql-18-citus-14.1 Install packages on Red Hat: curl https://install.citusdata.com/community/rpm.sh | sudo bash sudo yum install -y citus141_18 To add Citus to your local PostgreSQL database, add the following to postgresql.conf: shared_preload_libraries = 'citus' After restarting PostgreSQL, connect using psql and run: CREATE EXTENSION citus; You’re now ready to get started and use Citus tables on a single node. Install Citus on multiple nodes If you want to set up a multi-node cluster, you can also set up additional PostgreSQL nodes with the Citus extensions and add them to form a Citus cluster: -- before adding the first worker node, tell future worker nodes how to reach the coordinator SELECT citus_set_coordinator_host('10.0.0.1', 5432); -- add worker nodes SELECT citus_add_node('10.0.0.2', 5432); SELECT citus_add_node('10.0.0.3', 5432); -- rebalance the shards over the new worker nodes SELECT rebalance_table_shards(); For more details, see our documentation on how to set up a multi-node Citus cluster on various operating systems. Using Citus Once you have your Citus cluster, you can start creating distributed tables, reference tables and use columnar storage. Creating Distributed Tables The create_distributed_table UDF will transparently shard your table locally or across the worker nodes: CRE
Read the full README on GitHub

What Hacker News says

7 sources
(Ozgun from Citus Data) We're planning on supporting VIEWS (but not MATERIALIZED VIEWs) in Citus 6.1: https://github.com/citusdata/citus/issues/442 If you're interested in using Materialized Views in Citus, please feel free to comment on the issue or open a new one. We'd be happy to incorporate your feedback into upcoming releases. You're also correct in that the method presented in this blog post could be simulated with a distributed materialized view. One potential difference could be that materialized views in PostgreSQL currently refresh the entire data from source tables. This method provides flexibility to do rolling inserts or upserts.
In Real-time event aggregation at scale using Postgres with Citus
Roadmaps ( PostgreSQL ) 2016-2017-... * Postgres Professional roadmap ( Pluggable storages, Multimaster cluster with sharding, Effective partitioning, Adaptive query planning, Page-level data compression, Connection pooling, Native querying for jsonb with indexing support, ....) https://wiki.postgresql.org/wiki/Postgres_Professional_roadm... * EnterpriseDB database server roadmap ( Parallelism, Replication, Vertical Scalability, Performance ) https://wiki.postgresql.org/wiki/EnterpriseDB_database_serve... ==== And "Scalable PostgreSQL for real-time workloads https://www.citusdata.com " --> https://github.com/citusdata/citus
In Why Uber Engineering Switched from Postgres to MySQL
NEW: Scalable & Open Source PostgreSQL extension https://www.citusdata.com ( based on PG9.4 / PG9.5 ) Github: https://github.com/citusdata/citus HN: https://news.ycombinator.com/item?id=11353322 "Citus Unforks from PostgreSQL, Goes Open Source (citusdata.com)" ( 24th March, 2016 ) "What is Citus? - Open-source PostgreSQL extension (not a fork) - Scalable across multiple hosts through sharding and replication - Distributed engine for query parallelization - Highly available in the face of host failures " "Citus provides users real-time responsiveness over large datasets, most commonly seen in rapidly growing event systems or with time series data . Common uses include powering real-time analytic dashboards, exploratory queries on events as they happen, session analytics, and large data set archival and reporting." https://www.citusdata.co
Read the rest
In Analytics 101: Choosing the right database
(Ozgun from Citus Data) On PostgreSQL language support, we're updating our FAQ to have more information: https://www.citusdata.com/frequently-asked-questions Since the PostgreSQL manual (and its feature set) spans over 4K+ pages, we found that the best way to think about Citus' capabilities is from a use-case standpoint. If your workload needs distributed transactions that span across machines, or large ETL jobs, Citus currently isn't the best fit. Citus supports sharding and replication out of the box (#4, #5). On #6, reads go through a master node (metadata server) and you see what you write. We don't have #7. The way in which we implement this also has implications on your other questions. Multi-master (no single metadata server) is by far the biggest feature request that we receive: https://news.ycombinator.com/item?id=11353866 If we
Read the rest
go with the approach in https://github.com/citusdata/citus/issues/389, you will be able to configure #3, #6, #7 through PostgreSQL's streaming replication settings. We still won't support distributed transactions that span across multiple machines. On #8, could you elaborate a bit more? Do you mean a logical identifier for the node? Also, it's hard to write a concise reply on a topic that requires so much context. I'd love to grab coffee with anyone who's interested in diving deep into distributed databases. Feel free to shoot me an email at ozgun@citusdata.com
In Citus Unforks from PostgreSQL, Goes Open Source
(Ozgun from Citus Data) We're working on making Citus masterless. In all openness, we evaluated two different approaches to this in the past six months, and wrapped up the design for one. This design works well on the cloud, and we already demonstrated a working version: https://youtu.be/_nun2S6EdWo?t=411 For on-premise deployments, the primary challenge is set-up complexity. We're now prototyping one of those designs to know more: https://github.com/citusdata/citus/issues/389 We expect to share all the details and a concrete timeline in April.
In Citus Unforks from PostgreSQL, Goes Open Source

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.