HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
citusdata
cstore_fdw
C2014–2024
citusdata / cstore_fdw

cstore_fdw

Columnar storage extension for Postgres built as a foreign data wrapper. Check out https://github.com/citusdata/citus for a modernized columnar storage implementation built as a table access method.

33Distinct people
36Mentions
0Explicit recommenders
1.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Columnar storage extension for Postgres built as a foreign data wrapper. Check out https://github.com/citusdata/citus for a modernized columnar storage implementation built as a table access method.

GitHub

Where it is used

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

What people are saying

No recommendation phrase was found in the indexed comments.

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

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM 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 year36 dated mentions

Observed mentions: 2014-04-03 19:21:05 UTC to 2024-02-22 06:09:13 UTC.

02462014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 2 submissions, 3 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

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
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC707
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC716
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC523
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC514
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC505
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC303
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

From the project README

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

Read the project’s introduction
Important notice: Columnar storage is now part of Citus Columnar storage is now part of the Citus extension, which uses the table access method API to give a much more native experience. It also supports streaming replication, archival, rollback, and simplifies pg_upgrade. You can use Citus just for columnar storage on a single PostgreSQL server, or combine it with distributed tables to parallelize queries locally or across a cluster of PostgreSQL servers. Migration is simple, and you'll typically see improved compression thanks to zstd: -- After adding adding shared_preload_libraries = 'citus' -- to postgresql.conf and restarting: CREATE EXTENSION IF NOT EXISTS citus; -- Create a table using the columnar access method, with the same columns -- as an existing cstore_fdw table CREATE TABLE customer_reviews_am ( LIKE customer_reviews_fdw INCLUDING ALL ) USING columnar; -- Copy data from an old cstore_fdw table to an access method table INSERT INTO customer_reviews_am SELECT * FROM customer_reviews_fdw; -- cstore_fdw data size SELECT pg_size_pretty(cstore_table_size('customer_reviews_fdw')); ┌────────────────┐ │ pg_size_pretty │ ├────────────────┤ │ 100 MB │ └────────────────┘ -- Citus Columnar data size SELECT pg_size_pretty(pg_table_size('customer_reviews_am')); ┌────────────────┐ │ pg_size_pretty │ ├────────────────┤ │ 64 MB │ └────────────────┘ Read more about it in the Citus columnar blog post by Jeff Davis. cstore_fdw Cstore_fdw is an open source columnar store extension for PostgreSQL. Columnar stores provide notable benefits for analytics use cases where data is loaded in batches. Cstore_fdw’s columnar nature delivers performance by only reading relevant data from disk, and it may compress data 6x-10x to reduce space requirements for data archival. Cstore_fdw is developed by Citus Data and can be used in combination with Citus, a postgres extension that intelligently distributes your data and queries across many nodes so your database can scale and your queries are fast. If you have any questions about how Citus can help you scale or how to use Citus in combination with cstore_fdw, please let us know. Join the Mailing List to stay on top of the latest developments for Cstore_fdw. Introduction This extension uses a format for its data layout that is inspired by ORC, the Optimized Row Columnar format. Like ORC, the cstore format improves upon RCFile developed at Facebook, and brings the following benefits: Compression: Reduces in-memory and on-disk data size by 2-4x. Can be extended to support different codecs. Column projections: Only reads column data relevant to the query. Improves performance for I/O bound queries. Skip indexes: Stores min/max statistics for row groups, and uses them to skip over unrelated rows. Further, we used the Postgres foreign data wrapper APIs and type representations with this extension. This brings: Support for 40+ Postgres data types. The user can also create new types and use them. Statistics collection. PostgreSQL's query optimizer uses these stats to evaluate different query plans and pick the best one. Simple setup. Create foreign table and copy data. Run SQL. Building cstore_fdw depends on protobuf-c for serializing and deserializing table metadata. So we need to install these packages first: # Fedora 17+, CentOS, and Amazon Linux sudo yum install protobuf-c-devel # Ubuntu 10.4+ sudo apt-get install protobuf-c-compiler sudo apt-get install libprotobuf-c0-dev # Ubuntu 18.4+ sudo apt-get install protobuf-c-compiler sudo apt-get install libprotobuf-c-dev # Mac OS X brew install protobuf-c Note. In CentOS 5, 6, and 7, you may need to install or update EPEL 5, 6, or 7 repositories. See this page for instructions. Note. In Amazon Linux, the EPEL repository is installed by default, but not enabled. See these instructions for how to enable it. Once you have protobuf-c installed on your machine, you are ready to build cstore_fdw. For this, you need to include the pg_config directory path in your make command. This path is typically the same as your PostgreSQL installation's bin/ directory path. For example: PATH=/usr/local/pgsql/bin/:$PATH make sudo PATH=/usr/local/pgsql/bin/:$PATH make install Note. cstore_fdw requires PostgreSQL version from 9.3 to 12. It doesn't support earlier versions of PostgreSQL. Usage Before using cstore_fdw, you need to add it to shared_preload_libraries in your postgresql.conf and restart Postgres: shared_preload_libraries = 'cstore_fdw' # (change requires restart) The following parameters can be set on a cstore foreign table object. filename (optional): The absolute path to the location for storing table data. If you don't specify the filename option, cstore_fdw will automatically choose the $PGDATA/cstore_fdw directory to store the files. If specified the value of this parameter will be used as a prefix for all files created to store table data. For example, the value /cstore_fdw/my_table could result in the files /cstore_fdw/my_table and /cstore_fdw/my_table.footer being used to manage table data. compression (optional): The compression used for compressing value streams. Valid options are none and pglz. The default is none. stripe_row_count (optional): Number of rows per stripe. The default is 150000. Reducing this decreases the amount memory used for loading data and querying, but also decreases the performance. block_row_count (optional): Number of rows per column block. The default is 10000. cstore_fdw compresses, creates skip indexes, and reads from disk at the block granularity. Increasing this value helps with compression and results in fewer reads from disk. However, higher values also reduce the probability of skipping over unrelated row blocks. To load or append data into a cstore table, you have two options: You can use the COPY command to load or append data from a file, a program, or STDIN. You can use the INSERT INTO cstore_table SELECT ... syntax to load or append data fr
Read the full README on GitHub

What Hacker News says

7 sources
(Ozgun from Citus Data here) We're actively working on improving the cstore_fdw extension and your feedback is valuable to us. We're keeping a list of open issues on GitHub, and prioritize them for upcoming releases based on your comments. If you have any requests, please give us your feedback here: https://github.com/citusdata/cstore_fdw/issues For performance and compression related questions, we'd also love to hear more from you and help if we can in any way: https://groups.google.com/forum/#!forum/cstore-users As PostgreSQL covers a huge feature set, we know that it will take time on our end to get there. Some of that will involve new foreign table features from PostgreSQL core, such as foreign indexes and foreign table inheritance. I just wanted to let you know that we are working hard in that journey to get there.
In My wish list for Postgres 9.5
Anyone who likes Postgres and is looking for a good analytics DB should check out the cstore_fdw Postgres extension. [1] It allows Postgres to create and query files in the Optimized Row Columnar (ORC) format [2] from Hive. It was created and recently open-sourced by Citus Data (YC S11), who've made it a key component of their MPP Postgres offering. I don't work there. I'm just a fan. [1] https://github.com/citusdata/cstore_fdw [2] http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.0.2/ds...
In Moving product recommendations from Hadoop to Redshift saves us time and money
Good work, and I'm impressed by the PostgreSQL foreign data wrapped API power to allow for such ease of implementation. The .proto defined for cstore_fwd differs from the ORC as defined for Hive. At a quick glance I can't find references to dictionary encoding nor statistics, and the datatypes used are apparently the native PostgreSQL data types. From what I can tell this implementation leverages reduced IO (fetch only columns of interest from disk), segment elimination (use min/max info to skip over entire row groups) and pgzl compression for the data stream. I couldn't find references to run-length encoding (RLE) or dictionary encoding. I'm sure the shortcoming will be improved in future iterations, specially better encoding schemes which would result in better compression. But I'm a bit disappointed that the ORC format used is not the
Read the rest
same as the one originally used in Hive, Pig and the rest of Java/Hadoop ecosystem. Had it shared the actual file format it would had enabled a number of very interesting scenarios. Think about Hive/PIG serving as ETL pipelines to produce ORC file that are attached directly to PostgreSQL (add today's partition as FOREIGN DATA WRAPPER ... OPTIONS (filename '.../4_4_2014.cstore') and then do interactive analytic driven by PostgreSQL. It would reduce the cost of ingress significantly (fast attach, no need for expensive INSERT and re-compression). I realize data type translation would had been thorny, to say the least (datetime and decimal as primitives, probably many of the structured types too). - github.com/citusdata/cstore_fdw/blob/master/cstore.proto - github.com/apache/hive/blob/trunk/ql/src/protobuf/org/apache/hadoop/hive/ql/io/orc/orc_proto.proto
In PostgreSQL Columnar Store for Analytic Workloads

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.