Also, it’s our team’s favorite engine to translate both foreign SQL and foreign applications for PostgreSQL! We believe in transitions, not migrations - a gradual shift from the old database engine to the new, specifically to reduce risk and optimize results. Using a project like this makes a huge difference in achieving both these goals.
It’s been a little bit since the latest major version was released, but we’re still excited about what’s new and wanted to share.
Version 5.0 (release notes) came out on November 25, 2025 and there’s already been a minor version released since then (5.1 release notes) on December 18, 2025. These editions of the project were the direct result of massive efforts from the IvorySQL team to provide a lot of quality feature improvements as well as implement PostgreSQL 18 compatibility.
IvorySQL 5 brought a lot of necessary changes with it, including:
In particular, we really enjoy a lot of the functionality upgrades.
For example, IvorySQL now has better NULL handling, where NULL is now treated like an empty string in compatible mode (matching Oracle behavior) to avoid bugs during migration. So, when you have situations such as SELECT CONCAT('a' || NULL), IvorySQL will now return 'a' instead of following PostgreSQL’s behavior of returning NULL.
One enhancement we really enjoy is that you can now nest functions and procedures. Functions are able to be embedded inside other functions (like Oracle packages, but simpler, using only private methods). This lets you organize complex logic in one place.
Along the same lines, support was also added for DO [ LANGUAGE lang_name ] code [USING IN | OUT | IN OUT, ...].
Currently, we’re ingesting applications that range from only a few packages, procedures, and functions (around 10-50 objects) to massive data loads that include around 50,000 objects (10,000+ procedures and hundreds of packages).
While there are still many features that will need to be added over time, it considerably reduces the effort taken to complete the transition from Oracle to PostgreSQL successfully.
If you’re thinking about testing it for yourself, there are a plethora of options to get started (including building it from source, using containers, etc.)… and even a WASM build! This in particular allows IvorySQL to be run directly in the browser without having to fully install it locally; it’s very convenient to look at syntax support and take the first step into the world of PostgreSQL.
You can deploy the IvorySQL-WASM project locally in just a few steps, following the blog post IvorySQL published on the subject.
Or, you can try out the hosted WASM on the IvorySQL website.
Hoping to learn more about how to use IvorySQL yourself? Keep an eye out for recorded webinars on their website (coming soon!), or check out recordings from the HOW2025 conference in Jinan, China in the meantime.
The next conference in Jinan is already scheduled, from April 26th to the 28th! (By the way, the Call for Proposals is open until February 27th, 2026.)
Our team is happy to employ contributors to the IvorySQL project. Some of our team members (Cédric Villemain, Yasir Hussain Shah) have been recognized in the release notes for 5.0 and 5.1 - and we have more additions planned. For the next release, we have planned some exciting developments, including:
ENABLE/DISABLE constraint syntaxUTL_FILE package additionCREATE TRIGGER body (without needing to create a function beforehand)(+)We’re looking forward to seeing the result of ongoing community work for the next release as well. Many great features are actively being added; for example, recently a new contributor to the project, Rophy Tsai, added the DBMS_OUTPUT and DBMS_UTILITY packages: something widely used across Oracle-based SQL codebases. It was recently merged to IvorySQL’s main branch, and will likely be included in the next minor or major release.
For those looking to transition to or explore PostgreSQL without extensive modifications to their existing database logic and applications, IvorySQL (specially v5.x) offers a practical solution. A direct migration to PostgreSQL could, in some cases, require significant changes to both database objects and application code. IvorySQL helps bridge this gap, allowing a smoother adoption of PostgreSQL with greater compatibility.
That particular atmospheric event followed major heatwaves and broken records across the U.S., Europe, and Asia in the past few years. Just this last week at the time of this article, there has been historic flooding with profound damage in Washington state (U.S.)… more than nine million acre-feet of water dumped on the state over ten days… with the torrential downpour predicted to continue throughout the West Coast the rest of the year.
I don’t know if the relevancy of Ibiza’s floods in particular played a part in the way my short talk at the conference was received, but I am still grateful the topic at hand was not only heard, but listened to - even thought about and discussed. I must admit I was not expecting that.
I am part of those who believe that global environmental challenges are about to completely transform our societies on every level as resources get more limited and redistributed. I am the one asking around if anyone else wonders “what good will my comfortable salary do me if potatoes can’t grow anymore?”. Maslow clearly illustrated that it is less necessary to be rich than fed. Yet, as we all know, the environment is still not priority one, even after all this time and all the lessons we’ve experienced.
So, for me it made sense to discuss the topic at a PostgreSQL conference, because it should simply be discussed everywhere. It is a topic that is relevant to each and every one of us, because it involves the Earth itself that we reside on and take for granted. Yet, was I confident about finding a receptive audience? Nope!
I felt slightly uncomfortable – I usually do as a non-tech person at a technical event… – for taking the audience into a space they were not necessarily there for. I was hoping I would not bore, or bother, or even annoy. But after only the first few slides I saw that people were taking pictures of the data I was sharing, some were nodding, some were seeing those figures for the first time and raised an eyebrow. And when I linked it all with what we do daily and the impact of the digital pollution we produce, instead of facing disinterest or disapproval I got “why not!” looks in the room.
According to Greenpeace, digital pollution refers to all forms of pollution caused by the IT sector: greenhouse gas emissions, chemical contamination, erosion of biodiversity, and production of electronic waste.
Yes, there are some innovative solutions being designed to handle some of this digital pollution. For example, some situations are ideal for creating data centers that are able to use the heat they produce in order to heat nearby offices or homes. Projects such as Amazon’s Tallaght project is “the first large-scale district heating network of its kind in Ireland”, helping to “significantly reduce emissions in the area by almost 1,500 tonnes of CO2/year, establishing Tallaght as a leader in local energy action” (source).
However, the growth in the number of users equipped with at least one connected terminal (especially in developing countries), the increase in the ratio of the number of connected terminals per individual (from 2.1 in 2015 to 3.3 in 2020 on average worldwide), the increase in video traffic coupled with the increasing share of HD and UHD quality images and the shift of usage to consumption on demand (streaming, VOD, cloud gaming) have resulted in an explosion of traffic on networks (more than 25% per year) and in data centers (more than 35% per year). This growth is occurring at a rate that surpasses energy efficiency gains in equipment, networks and data centers. These traffic forecasts are also regularly revised upwards.
Although the number of “standard” devices (excluding connected objects) has increased significantly between 2000 and 2015, it stabilises between 2015 and 2025 because the market is saturated.
Although the mass per user decreases slightly, from 63 kg CO2 emmissions to 58 kg between 2010 and 2025, the total mass (user equipment, networks, data centres) is multiplied by more than 2.5 in 15 years: it increases from 128 million tonnes in 2010 to 317 million tonnes in 2025.
This explains the stress on raw materials, especially “conflict minerals” and other rare earths.
Performance optimization for databases doesn’t just result in improved costs and speed. When we work on improving a query, we save that little bit of extra energy that would have been used to read/write, that extra disk movement that was always unnecessary. Other essential responsible practices that in a clever way allow you to better harness the power of technology results not just in a more technically efficient result but also - without realizing or thinking about it - doing some good for the planet.
For example, some actions we commonly consider for our own good that have an equally beneficial result for our planet include:
We need to think about digital sobriety, thoughtful coding practices and considerate energy consumption as being the key to greener coding and integrate that parameter in the way we work every day and in the way we build, manage and develop database solutions in order to minimize our environmental footprints as much as possible. These kinds of actions can generate significant cost savings for our own companies and for our customers, which can then be reinvested in R&D projects to increase energy efficiency. It’s a virtuous circle.
A closing thought to this section: AI in particular drives far higher water usage, emissions, and e-waste (training AI models is one of the most resource-intensive computing tasks on the planet!). In a world where it has become common to integrate AI into every corner of applications and day-to-day coding practices, being deliberate in how such technologies are used to ensure they are truly the best solution for the problem at hand has a huge impact. Is AI really the most appropriate solution for that issue you’ve been thinking about? Or are you considering its usage merely because it’s easier to implement than something more technically involved?
And that’s an interesting twist to consider regarding our day-to-day. We sometimes complain about needing to know there’s meaning to what we do; well here’s some food for thought to fuel your complaints!
A brief note from our Marketing team here at Data Bene: our team of experienced PostgreSQL engineers can help with improving your own energy efficiency, database optimizations, and thoughtful coding practices that will result in direct benefits to you: speedier database operations, decreased resource usage, lessened costs, and a greener planet. Curious about what we offer? Get in touch - we’d love to chat.
]]>The event lasted two days, featuring 90 exhibitors, 130 sessions, 150 speakers, and over 4,000 participants – a truly large-scale conference held at the Cité des Sciences et de l’Industrie in Paris.
This particular venue was smaller than last year’s venue (Le Palais de Congrés) and the rooms we went to were all full as a result of being very small (about 20 or 30 seats or so at most).
Presentations were given in both English and French. Interestingly, there were no “silent rooms” this year (where headphones are provided to each attendee). Not everyone enjoyed that format last year, but it was a useful one for following two talks, or switching between them depending on the content or questions.
Two of our team members were in attendance and had the opportunity to explore various exhibitors and event rooms spread across three floors. The talks lasted 20 minutes. While too short to delve into details, this format was excellent for discovering new technologies and piquing our interest at a glance.
There were six tracks that talks were categorized by:
We found the topic of open source solutions within the public sector to be the most interesting. In particular, it was easy to see our reliance as a global society on the big five tech companies (GAFAM: Google, Apple, Facebook, Amazon, and Microsoft) has grown significantly in the past few years. Open source software is a direct solution for protecting our collective right to privacy in the digital age, which is exactly why conferences such as this are so important for the discovery of OSS alternatives and innovation that leads to further development within this sector.
Attendance was particularly high from the very first day. We were delighted to have the opportunity to interact in person and meet our partners, especially OW2, which also organizes an annual Open Source event in June. (The call for presentations is open until February 14, 2026 – see the OW2Con’26 call for proposals here.)
Since the event was entirely focused on open source technologies, we were able to discuss with numerous participants topics such as PostgreSQL support, along with the challenges and organizational impacts for companies wishing to innovate and adopt PostgreSQL, against the backdrop of market demand to break free from proprietary software licensing constraints.
We also had the pleasure of meeting key players in open source hardware innovation, which resonates with our own R&D on RISC-V processors.
Many free software and open source projects were represented. Some examples include Nextcloud (a self-hosted cloud collaboration platform that we personally use for hosting here at Data Bene) and OpenTalk, a video-conferencing solution that is GDPR-compliant, operating within German data centers.
The event was successful and well-organized. The only thing that would have improved the experience would have been longer presentations to explore the various topics discussed in more depth. If you want to discover new open source projects, note that this event is also a great opportunity to freely exchange ideas on these topics.
The video replays for 2025 have not yet been published, but past conference recordings can be found on the official website, here.
Overall, we thoroughly enjoyed the event and hope to attend next year!
]]>This was the first time that the Data Bene team attended the event, and we’re happy to share that it was a very positive experience.
As its name suggests, this conference takes place on the Mediterranean island of Ibiza. For those who are less familiar, the Official Tourism Site provides a nice overview that you may refer to. While it should go without saying, this UNESCO World Heritage Site has incredible offerings outside of the conference itself. Combined with a potentially long-haul flight, it’s strongly recommended to plan an extra day or two (or more) to explore the island and enjoy the local experience.
The event itself is hosted at the Palacio de Congresos de Ibiza; a two-story conference center with multiple rooms and catering. Though located outside of the capital city, the venue can be reached by car in good timing (~15 minutes). To add, the venue is situated within walking distance of numerous hotels, restaurants, and a beach! We happened to have stayed at Hotel Tres Torres, which we can recommend, though admittedly it’s difficult to make a wrong decision, especially following a sprinkle of background research.
Briefly, on the topic of extracurriculars, our go-to recommendation would be to visit the capital city, Ibiza. There you will be able to find a surprisingly large amount of shopping, restaurants, and sightseeing. Adding to that a walk through the historic neighborhood and you’ve got quite the memorable experience.
This year’s PGIBZ welcomed about 30-40 attendees from across the globe, including China and the United States. And while there are certainly two sides to the coin, I consider this group size as more of a positive. Indeed, during both the presentation Q/A sessions, as well as the coffee breaks, I felt interactions were more engaging overall. This was especially true when meeting and reconnecting with members of both more modest and global enterprise-scaled companies.
The first of the Data Bene speakers, and indeed the keynote of the first day, was Catherine Bouxin. Her presentation addressed the environmental impact of technology, and reflected the philosophy that important topics are not always the ones being discussed, and often aren’t considered a concern at all! Indeed, Catherine framed this conversation primarily as a reminder of the responsibility we as PostgreSQL community members share. There have been many exciting inventions of late, some with societal-changing implications, but we can not ignore the resource intensity that many of them require.
We stand confidently with Catherine’s message about contributing towards a greener future and making thoughtful decisions to this end, and we are excited that this was very well-received by the audience.
On second day, our founder and CEO, Cédric Villemain, presented on the statistics-based highlights of the PostgreSQL major release version 18 (official notes linked here). (After the event, he created a blog post on the topic of Cumulative Statistics in Postgres 18 - check it out here!) Our team here at Data Bene are a fan of stats and surfacing data, which is what led us to create the PostgreSQL extension, StatsMgr. If you previously missed information on StatsMgr and would like to learn more, check out our previous blog and Postgres Café podcast episode on the topic.
Directly after Cedric, I had the opportunity to present on developing and maintaining a Rust-based PostgreSQL extension (currently still very early stage) that helps facilitate the transition from Oracle to PostgreSQL. This project, named pgtap_gen, leverages the pre-existing pgTAP project to automate unit test creation on IvorySQL (100% open-source forked PostgreSQL with Oracle-analogous components). It was very encouraging to hear audience engagement and feedback. What’s more, it feels great to participate in the PostgreSQL ecosystem, even if it’s for proof-of-concept initiatives!
Towards the end of the second day, Frédéric delievered a talk on transaction isolation levels in PostgreSQL (that you may get the chance to see later on, as he’s submitted the same talk to pgDay Paris 2026 and PGDay CERN 2026!). He delved into each isolation level in Postgres with practical examples, and explained how everything works behind the scenes to define real steps for confidently choosing the right level for the right context. The attendees seemed to find the talk interesting and educational, so we may yet see further content on this topic and similar to help others who missed the opportunity to learn about the subject.
We chose to sponsor and attend PGIBZ 2025 as we believe it is important to further the PostgreSQL community across the world. No matter what, this is an event that is seeking to further Postgres education for the better. Profits from the event are used by the parent nonprofit organization, PostgreSQL España, to invest in translations of the official PostgreSQL documentation into Spanish.
Further breakdowns of each of the talk topics mentioned above are in-the-works; feel free to follow us on LinkedIn and Mastodon to keep an eye out for them when they’re published on our blog.
We very much enjoyed our time at PGIBZ 2025, and are honored to have had the opportunity to present and participate. Looking forward to returning next year!
More and more companies are seeking to free themselves from the costs and constraints of Oracle by migrating to PostgreSQL. But how can this transition be achieved without spending months on it? Here is a proven, fast and secure method, based on feedback and open source tools.
Before migrating, it is essential to take stock of the situation: we start by listing Oracle objects through performing a complete extraction (including tables, views, sequences, procedures, functions, and packages).
It is also important to communicate regularly with the client to refine findings and validate directions, as well as to identify dependencies (applications connected with which technology, jobs, interfaces, etc.).
Finally, identify the client’s Oracle-specific features (specific functions such as ROWID, DUAL, DBMS_XXX, etc.) and any other keywords requiring special attention.
The success of a transition to PostgreSQL – because it is indeed a gradual transition and not a migration – depends as much on strategy as it does on tools.
It is not enough to simply copy objects: you need to understand the subtleties of the Oracle engine and intelligently transpose them into the PostgreSQL universe.
Among the essential tools, Ora2Pg plays a central role. Not only does it generate clear inventory reports, it also automates the conversion of schemas, data and PL/SQL code. It is a valuable accelerator for well-structured projects.
But in some contexts, the reality is more complex. Many customers accumulate significant technical debt, with thousands of lines of procedural code. Attempting to rewrite everything in PL/pgSQL in a short period of time would exhaust teams and compromise the migration itself. Maintaining two code bases— one in PL/SQL, the other in PL/pgSQL— during a complete transition phase is often organisationally untenable.
This is precisely where IvorySQL offers a powerful alternative. This fork of PostgreSQL, enhanced with Oracle compatibilities (PL/SQL, ROWID, DUAL, etc.), significantly reduces the need for immediate rewriting. By combining IvorySQL with targeted documentation and business validation scripts, the transition is easier, more reliable, and above all, more controlled.
Once in production, teams have the time they need to gradually rewrite their procedural and remaining application code in PL/pgSQL, without pressure or functional disruption.
One of the great advantages of IvorySQL is that it performs part of the integration upstream. Thanks to its native support for PL/SQL, Oracle objects and Oracle-compatible syntax, many elements migrated via Ora2Pg work immediately without any major adaptation.
Of course, this does not eliminate the need for testing. On the contrary, it is essential to validate business behaviour in an IvorySQL pre-production environment. Procedures, functions, packages, triggers, and views must be tested with real-world cases, comparing the results between Oracle and IvorySQL to ensure functional equivalence.
Comparison scripts can be used to verify query responses, transaction effects, or the behaviour of migrated functions. But in many cases, IvorySQL significantly reduces the need for patches or rewrites, speeding up production and securing the transition.
A successful transition is not limited to technical aspects; it also relies on clear documentation and appropriate support. It is essential to write comprehensive test specifications for each complex object and module (procedure, package, trigger, etc.) in order to keep track of technical choices, adaptations made, and points of attention.
Support for client teams is just as important. Targeted workshops are used to share best practices, explain the differences between Oracle and PostgreSQL, and facilitate the adoption of IvorySQL.
Finally, a successful transition to PostgreSQL also depends on support for technical and functional teams. Targeted training sessions enable developers, DBAs, and project managers to learn the specifics of IvorySQL, understand the differences with Oracle, and quickly develop their skills.
This system also relies on structured technical support, which helps resolve issues, secure implementation choices, and facilitate communication between project teams and migration experts.
During a recent assignment for a private sector company, we supported the transition from an Oracle database to IvorySQL in a challenging context: where there was significant technical debt, high volume, and tight deadlines.
Thanks to IvorySQL and our ability to automate this transition, it was completed quickly and almost all objects were integrated without rewriting.
The switch from IvorySQL to PostgreSQL can be carried out smoothly, as long as the application is fully functional and meets business expectations.
The teams were able to focus on business testing, while targeted training and technical support enabled rapid skill development.
It is essential to succeed in this type of project in order to build confidence and roll out this operation across your entire Oracle instance fleet!
Are you considering a transition from Oracle to PostgreSQL? Let’s talk about it.
Contact our team of experts at any time: contact@data-bene.io
On November 26, 2025 IvorySQL 5.0 was released - view the announcement here for more information about this open-source project.
]]>The PostgreSQL documentation Appendix K states a table can have a maximum of 1,600 columns.
This is a hard coded limit that can be found in the source code at src/include/access/htup_details.h:
#define MaxTupleAttributeNumber 1664
#define MaxHeapAttributeNumber 1600Let’s fully validate the claim and test accordingly.
Here, we’ll use a simple bash script because it is easy to adapt while testing.
-- Classic example
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1601;';
EXECUTE 'CREATE TABLE tint_1601(i_1 int);';
FOR i IN 2..1601 LOOP
EXECUTE format('ALTER TABLE tint_1601 ADD COLUMN i_%s int;', i);
END LOOP;
END $$;The typical output is as follows:
NOTICE: table "tint_1600" does not exist, skipping
ERROR: tables can have at most 1600 columns
CONTEXT: SQL statement "ALTER TABLE tint_1600 ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTESo far so good (or at least, all is working as expected).
You might have the idea to try replacing int4 with int2 type to create a 1,600+ column table. It will not work as this is a hard coded limit.
Let’s build a 1,600 column table with the same demonstrated code.
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
FOR i IN 2..1600 LOOP
EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN i_%s int;', i);
END LOOP;
END $$;Another sql script can be used to produce a valid 1,600 column tuple:
DO $$
DECLARE
s TEXT;
rows_inserted int;
BEGIN
s := format(
'INSERT INTO tint_1600 VALUES (1%s);'
, repeat( ',1' , 1599 )
);
EXECUTE s;
GET DIAGNOSTICS rows_inserted = ROW_COUNT;
RAISE NOTICE 'Rows inserted: %', rows_inserted;
END $$;The output is:
NOTICE: Rows inserted: 1
DOAnother success with no surprise.
Let us continue pushing to the limits.
We now create another 1,600 column table using the char(127) data type.
We reuse our sql script with some modifications:
-- Create a table with 1,600 columns: 1 x int + 1599 x char(127)
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
FOR i IN 2..1600 LOOP
EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN c_%s char(127) NOT NULL;', i);
END LOOP;
END $$;
-- Insert a tuple - 1 x int + 1599 x char(127)
DO $$
DECLARE
s TEXT;
BEGIN
s := format(
'INSERT INTO tint_1600 VALUES (1%s);'
, repeat( $q$,'1'::char(127)$q$ , 1599 )
);
EXECUTE s;
END $$;The output is:
ERROR: row is too big: size 25616, maximum size 8160As we can see, the table has 1,600 columns but this time the tuple cannot fit a single heap page which explains the error “row is too big: size 25616, maximum size 8160”. If you paid attention to the modified script, you can see columns are defined as NOT NULL so at table creation PostgreSQL could have proven data insertion was impossible.
To keep things simple, let us auto-join:
SELECT a.*,b.* FROM tint_1600 a, tint_1600 b;
ERROR: target lists can have at most 1664 entriesNow the SELECT clause (a.*,b.*) is reaching its own limit (MaxTupleAttributeNumber = 1664).
Sometimes, you have to modify your application and it generates schema modifications.
Most of the time, there are table modifications like adding or dropping columns.
ADD / DROP COLUMNLet us see what happens from the SQL side when we add, then drop, a column.
=# CREATE TABLE tadc_1600(i_1 int NOT NULL);
CREATE TABLE
=# ALTER TABLE tadc_1600 ADD COLUMN i_2 int NOT NULL;
ALTER TABLE
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc_1600'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
---------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
i_2 | 2 | p | t | f
(2 rows)
=# ALTER TABLE tadc_1600 DROP COLUMN i_2;
ALTER TABLE
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc_1600'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
------------------------------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
........pg.dropped.2........ | 2 | p | f | t
(2 rows)When dropping a column,
One can wonder if there is a limit to the number of add/drop operations that can be run on a given table.
As usual, let us try:
-- ADD / DROP COLUMN example
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tadc;';
EXECUTE 'CREATE TABLE tadc(i_1 int);';
FOR i IN 2..1601 LOOP
EXECUTE format('ALTER TABLE tadc ADD COLUMN i_%s int;', i);
EXECUTE format('ALTER TABLE tadc DROP COLUMN i_%s;', i);
END LOOP;
END $$;The output is:
ERROR: tables can have at most 1600 columns
CONTEXT: SQL statement "ALTER TABLE tadc ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTEOh oh! We reached the 1,600 limit here as well.
Let us explore a bit after add/drop column 1,599 times:
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
---------------------------------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
........pg.dropped.2........ | 2 | p | f | t
........pg.dropped.3........ | 3 | p | f | t
........pg.dropped.4........ | 4 | p | f | t
........pg.dropped.5........ | 5 | p | f | t
........pg.dropped.1599........ | 1599 | p | f | t
........pg.dropped.1600........ | 1600 | p | f | t
(1600 rows)Well, table tadc has 1,600 columns. You can see this as modifications are appending and table content rewriting is avoided.
At this point, further column add & drop modifications will fail.
Is there anything I can do to escape this situation?
The VACUUM command operates at the tuple level so even if you run a VACUUM FULL the table structure will not change.
This is not an issue with dead tuples but rather an issue with the catalog.
You’ll need to create a new table definition.
Here are some solutions, from simple to complex:
Build a new table (requires service downtime)
CREATE TABLE (LIKE INCLUDING ALL)COPY data from old to new tableLeverage logical replication (minimize service downtime)
CREATE TABLE LIKE (INCLUDING ALL)CREATE local PUBLICATION/SUBSCRIPTIONThe above solution works fine for simple cases. But real life tables often
use integrity constraints. Let’s explore a bit using foreign keys.
-- Foreign key case
=# CREATE TABLE colors (id int, name text );
=# CREATE TABLE objects ( id int, color_id int, name text );
=# ALTER TABLE colors ADD PRIMARY KEY (id);
=# ALTER TABLE objects ADD CONSTRAINT fk_color
FOREIGN KEY (color_id) REFERENCES colors (id);
=# INSERT INTO colors
VALUES (1,'red'), (2, 'green'), (3, 'blue' );
=# INSERT INTO objects
VALUES (1,1, 'red object')
,(2,2, 'green object')
,(3,3,'blue object');Let’s apply the recipe:
-- Duplicate table structure (valid columns only) and copy data
=# CREATE TABLE tmp_colors (LIKE colors INCLUDING ALL);
=# INSERT INTO tmp_colors SELECT * FROM colors;
-- Do the DROP/RENAME trick
=# BEGIN;
=# DROP TABLE colors;
=# ALTER TABLE tmp_colors RENAME TO colors;
=# COMMIT;The DROP TABLE command issued an error:
ERROR: cannot drop table colors because other objects depend on it
DETAIL: constraint fk_color on table objects depends on table colors
HINT: Use DROP ... CASCADE to drop the dependent objects too.As we can see, the recipe has to be changed to include dependent tables as well.
Adding CASCADE will drop FK constraints on dependent tables.
Let’s run a modified version of the recipe:
-- Do the DROP/RENAME trick
=# BEGIN;
=# DROP TABLE colors CASCADE; -- DROP related FOREIGN KEY constaints
=# ALTER TABLE tmp_colors RENAME TO colors;
-- Recreate FK contraint
=# ALTER TABLE objects ADD CONSTRAINT fk_color
FOREIGN KEY (color_id) REFERENCES colors (id);
COMMIT;We have to check the behaviour is the expected one:
=# INSERT INTO objects VALUES (5,5,'ro');
ERROR: insert or update on table "objects" violates foreign key constraint "fk_color"
DETAIL: Key (color_id)=(5) is not present in table "colors".
=# INSERT INTO objects VALUES (5,3,'ro');
INSERT 0 1Success!
When integrity constraints are too numerous or you find it difficult to follow,
you may use pg_dump/pg_restore to rebuild all automatically. If service downtime
is an issue, you may use logical replication to perform like pg_dump/pg_restore.
As you can see, having to deal with the 1,600 column limit is not something you would
like to do just for fun (usually). Notably, it can lead to service downtime.
Do you have other ideas of how to address this situation? Have you run into odd ways of reaching this hard-coded limit? Contact us! We always love a good discussion about PostgreSQL.
]]>The program featured 101 technical talks led by 105 speakers. The majority of sessions were in Mandarin, with an English track offered with simultaneous translation. You can view the full program at IvorySQL.io and find the replays on Weibo via this link.
There was a small group of the international community present, including Grant Zhou, who liaises and collaborates with the PostgreSQL association in China and the rest of the world.
On a technical level, the content was dense and particularly interesting. I particularly noted:
Alena Rybakina’s presentation on the PostgreSQL query planner and strategies for circumventing certain limitations.
A clear and concrete focus on Patroni (High Availability) by Alexander Kukushkin and Polina Bungina.
Florentz Tselai presented two topics applying his principles: simplicity and efficiency, using “AI” with PostgreSQL, and data management with Sun Tzu and the 36 Stratagems as support.
Also a very good introduction to Bazel and its use for Monogres (to be officially announced soon) presented energetically by Alvaro Hernandez.
Monogres is a very interesting initiative that should help strengthen control over the software supply chain, a major theme in IT today. And I also saw it as a great opportunity to showcase PostgreSQL variations with features and fixes that aren’t always possible to include in PostgreSQL itself or backport to previous major releases.
Michael Meskes had the honor of giving a plenary lecture on a topic that richly deserves it: “From Code to Commerce: Open Source Business Models Today,” a keynote on open-source and free software, applied to the PostgreSQL ecosystem.
My colleague Andrea presented the developments and trends of companies moving to IvorySQL and PostgreSQL.
For my part, I presented Linux PSI in the PostgreSQL context.
Since everything is recorded, I encourage you to explore and watch the topics that interest you. There were also pre-recorded lectures in English during the event, but I admit that I took advantage of the time during the sessions to interact with participants.
Aside from the conferences, I had the chance to meet several members of the Chinese PostgreSQL community who are very well-known for their involvement in the success of PostgreSQL locally. I also had the opportunity to learn more about Cloudberry, replacing Greenplum, thanks Dianjin Wang!
Data Bene also planned a time to meet with the IvorySQL team, based largely in Shandong, the province where Jinan, the host city of the conferences, is located. Ivory is a project in which we are actively involved and which allows companies to move away from Oracle “smoothly.” This is an important topic for our clients and one that occupies a prominent place in our partnership with Highgo: they have been working on this project for several years now, and we want to enable companies everywhere to benefit from it with appropriate support and expertise.
The conferences were very well organized and the welcome was wonderful, the “Social Event” at the local “beer garden” perfectly suited to the heat of Jinan at the end of June!
Given the conference program, I bitterly regretted not understanding anything (there was 1 track in English and 5 in Mandarin)… but it is already being said that next year the Mandarin conferences could perhaps be translated (into English), and the date brought forward to May to take advantage of a milder climate.
There is so much to learn there that I will gladly return.
]]>This year’s conference focused around the topics of AI, DevOps and cloud-native technologies, open source community engagement, security and compliance, systems and infrastructure, and FOSS @ home (exploring the world of self-hosted applications and cloud services).
The conference drew attendees from around the world to talk about everything open-source, revolving around Linux at the core (of course) while continuing the discussion across topics such as embedded systems & IoT. As always, there was a unique blend of cutting-edge tech talk and practical problem-solving within every space that is what makes SCaLE special.
PostgreSQL@SCaLE22x ran as a dedicated two-day, two-track event on March 6-7, 2025, recognized under the PostgreSQL Global Development Group community event guidelines. The selection team included Gabrielle Roth, Joe Conway, and Mark Wong, ensuring the quality you’d expect from the PostgreSQL community.
The speaker lineup was impressive: Magnus Hagander, Christophe Pettus, Peter Farkas, Devrim Gündüz, Hamid Akhtar, Henrietta Dombrovskaya, Shaun Thomas, Gülçin Yıldırım Jelínek & Andrew Farries, Nick Meyer, and Jimmy Angelakos. One particularly memorable session was titled “Row-Level Security Sucks. Can We Make It Usable?”—a refreshingly honest take on PostgreSQL’s RLS feature that probably resonated with more than a few database administrators in the audience.
The community “Ask Me Anything” panel was hosted by Stacey Haysler and featured Christophe Pettus, Devrim Gündüz, Jimmy Angelakos, Magnus Hagander, and Mark Wong. These sessions are where the real knowledge transfer happens—no marketing speak, just practitioners talking shop about PostgreSQL internals, performance, best practices, and the future of the database.
Behind the scenes, volunteers Derya Gumustel, Erika Miller, Hamid Akhtar, Jennifer Scheuerell, Mark Wong, and Roberto Mello kept everything running smoothly, with PGUS hosting the booth in the expo hall.
Personally, I had the pleasure of collaborating with Jimmy Angelakos during his live streaming sessions featuring other guests like Henrietta Dombrovskaya, Mark Wong, Gülçin Yıldırım Jelínek, and even a brief cameo from Devrim Gündüz.
One of the topics discussed with Gülçin Yıldırım Jelínek on the podcast is whether or not there’s any community interest in continuing Postgres Café. What do you think? Do you want to see more episodes from this podcast series, expanding discussions on extension and open source development to the rest of the community and beyond? Let us know: contact@data-bene.io
There are a lot of co-located events besides PostgreSQL @ SCaLE, including “SCaLE: The Next Generation (TNG)” which is a youth-focused tech event encouraging interactive activities and presentations for students, and the annual Cybersecurity Capture the Flag (CTF) game event presented by Cal Poly FAST and Pacific Hackers.
SCaLE remains an excellent place to network when looking to advance your career in open source. Socializing at the booths is always an excellent way to make connections and find opportunities, of course, but Open Source Career Day also returned in order to offer a dedicated space for professionals and aspiring technologists to become empowered with resources, tools, real-world examples, and engaging content from presentations and workshops.
The fun tradition of holding a Saturday Game Night with food & drinks also continued this year, with Trivia Night (presented by Uncoded) and other fun activities such as inflatable axe throwing, nerf target practice, arts & crafts, a board game room, casino night, & a blocks room for building derby cars, playing pictionary, or building with large blocks.
SCaLE has established itself as a consistent presence in Pasadena, and this stability has allowed the conference to build lasting relationships with the local community and venues. Keep an eye out for SCaLE 23x announcements - it promises to be well worth the visit.
For those interested in PostgreSQL@SCaLE specifically, stay tuned to the PostgreSQL mailing lists for announcements about volunteering, speaking opportunities, or other ways to participate in next year’s event. The PostgreSQL track and booth is a consistent source of engaging discussions amongst those in the Postgres community and beyond, reflecting the database’s growing adoption across industries.
In a world where many tech conferences feel more like elaborate vendor showcases, SCaLE remains that rare gathering where community comes first, collaboration is genuine, and the technology discussions are driven by practitioners solving real problems. Mark your calendars for SCaLE 23x—this is one conference that consistently delivers on its promise of bringing together open source enthusiasts to actually collaborate and learn.
Wish you hadn’t missed out? You can always check out the YouTube playlist of talks that were recorded during the conference to at least benefit from the knowledge contained therein.
]]>How often do companies express interest in open-source contribution? Clearly, by helping out in any way, the open-source project itself sees a benefit. But are there any advantages for the company that is giving back in any way? What are some contribution methods that a company can consider? These are all questions we hear about constantly—so let’s explore some of the answers discussed in this episode in a quick recap.
At Data Bene, we have a few customers that are interested in developing features or enhancements for the PostgreSQL ecosystem already.
These companies are interested in addressing bugs and adding new features that complement their use cases and tech stacks across PostgreSQL, Citus Data, and related technologies to accomplish two things:
Times change; the only way the upstream software will remain relevant, useful, and beneficial to the global audience using the product is if there are global contributions back to the same, ensuring it still meets real users needs from year to year.
Vendor lock-in is a huge problem in the software & services industry; giving back to open-source projects ensures that technology that is openly developed can continue to be so. Using FOSS technology means you avoid investing in a company that might close the code or restrict access, giving the end user freedom to continue using and developing essential tools that are part of their tech stack.
This kind of software is also subject to a highly visible development process, meaning it is much harder for privacy invasions, cybersecurity vulnerabilities, and more to be built into the underlying code.
Additionally, open-source software is built by individuals all over the world with a variety of perspectives and backgrounds; this ensures that it is thoroughly tested, with a wide range of features built-in that are actually useful to many end-users. This helps these kinds of projects to be successful for a number of years and continue to be so as long as there is a community willing to support each of them.
Case-in-point: PostgreSQL has been around for 35+ years of active development and is still topping developer surveys and charts today for being the most liked, most used, and most popular database solution—worldwide!
There are a few key ways to achieve this end-goal:
Cédric Villemain, Data Bene’s president, has developed pg_fincore and is currently working on StatsMgr, pg_psi, and other components that are designed to improve Postgres’ statistics capabilities.
Our team is also responsible for a number of contributions across projects like Citus Data and Zammad.
We make a point of sponsoring, presenting at, & advocating for PostgreSQL or open-source community conferences and user groups, such as PostgreSQL Europe, pgDay Paris, AlpOSS, Capitole du Libre, & more. Some of our team also individually have started or are on the organizational committees for various events such as the Barcelona & Madrid PostgreSQL User Groups and pgDay Lowlands. The impact of events on the larger project & community cannot be understated, and it is important to us to do all we can to contribute in this manner.
Finally, we help customers understand how to contribute to PostgreSQL and similar open-source projects. Through training, workshops, and collaboration, we encourage making meaningful contributions that fit their goals and support the greater community.
If you’re a developer who is interested in contributing to open-source and/or the PostgreSQL ecosystem, or helping customers with R&D requirements, our team is expanding—visit us at our website to see available positions!
Thinking about watching the full discussion? Check it out on YouTube:
We’ve finished our first round of episodes for Postgres Café as of this release! More episodes may or may not be pending… follow us on social media (like LinkedIn or Mastodon) to be updated on more to come. (Would you like to see more from this podcast series? Let us know!)
Subscribe to the playlist or check it out for interviews about open-source extensions like StatsMgr for efficient statistics management for PostgreSQL, an open-source change data capture (CDC) tool designed specifically for PostgreSQL called pgstream, & more. PostgreSQL is one of the most extensible databases on the market with a huge extension ecosystem; learn directly from the experts as you discover some of the options out there.
]]>