Executive summary
QUIQQER 2.31 is first and foremost a database release: the platform now supports both SQLite and PostgreSQL. SQLite is the standout addition. Because it runs as an embedded, file-based database without a separate database server, it makes lightweight installations, local development, testing, demos, and portable setups substantially easier. PostgreSQL support gives larger projects another established option for production infrastructure.
The release coordinates this work across Core, Requirements, Installer, and Utils, rather than treating database support as an isolated switch. It also improves everyday editing, installation, security, content building, and MCP integrations.
This report is based on the available release notes. It provides orientation across the release line, but it is not a substitute for reviewing dependencies, migrations, and local customizations before updating a production project.
What changed
SQLite and PostgreSQL broaden deployment options
SQLite gives QUIQQER a genuinely lightweight database option. A project can run with its database in a local file and without operating a separate database service. That lowers the setup barrier for development environments and small or self-contained installations, while making disposable test systems and portable project setups much more practical.
PostgreSQL support addresses the other end of the spectrum: teams with established PostgreSQL operations can now use that infrastructure for QUIQQER projects. Core 2.31.1, Requirements 3.3.0, Installer 1.10.3, and Utils 2.6.2 align database drivers and injected connections so both database options are supported across the relevant platform layers.
A more practical Core foundation
Core 2.31.1 also brings several changes aimed at everyday CMS work. Input and textarea controls can now show character counters, the site selector provides clearer details and layout, and the media manager asks for confirmation before replacing an upload. Runtime translations are cleared when locale data is refreshed, reducing the risk of stale labels remaining in a running session.
A shell-completion installer for the console rounds out the Core and setup improvements.
AI and automation interfaces become more useful
AI MCP 1.13.1 refines how public capabilities are exposed. Anonymous public providers are supported, the current project may be nullable, and public skills can be made available to restricted users through an explicit allowlist. These changes make public integrations more flexible while keeping access decisions visible in configuration.
Products 2.13.0 adds MCP tools for categories, product fields, products, and variants, together with more consistent boolean field attributes. Connected tools can therefore work with a larger part of the product model without relying on ad-hoc integration code.
Content editing and frontend behavior
Bricks 2.34.0 updates accordions to native details and summary elements and adds a direct edit action for bricks in multi-layout areas. Sticky vertical alignment, placeholder support in brick settings, and cleaner frontend markup address smaller issues that accumulate in daily editorial work.
Slider 2.7.0 adds a ring or bar indicator for autoplay timing and prevents borders from being clipped at fractional widths. Frontend Users 2.18.0 adds the well-known change-password redirect and aligns its types with current Core contracts.
Installation, security, and maintained integrations
Installer now registers template engines before setup, can retry Composer downloads over IPv4, prefers passwords supplied through the CLI, and uses Core database drivers. Utils adds strict SVG sanitization and improves legacy site-setting descriptions. Together with the database work, these changes make setup and content handling more predictable.
Booking 1.4.0 declares its reservation capability and aligns its provider contracts with ERP 4 interfaces. Static-analysis and coding-standard fixes complete that compatibility work.
What this means for projects
- Developers and small installations gain a simple SQLite path without a separately operated database server.
- Production teams can integrate QUIQQER into established PostgreSQL environments.
- Editors gain clearer controls, safer media replacement, and more direct brick editing.
- Integration teams can expose selected public AI capabilities and manage more product data through MCP.
- Frontend teams receive smaller accessibility, authentication, and rendering improvements.
Operational notes
Projects adopting SQLite should verify that installed drivers, local extensions, backup procedures, and the expected concurrency profile fit the intended workload. PostgreSQL deployments should likewise validate drivers, connection configuration, migrations, and project-specific queries before moving production systems. Installations that accept SVG uploads should test existing editorial workflows against the stricter sanitizer. Public AI MCP providers and skill allowlists should be reviewed as access-control changes, even where the provider itself is intended to be anonymous.
Looking ahead
SQLite and PostgreSQL support materially widen where and how QUIQQER can be deployed. SQLite makes the platform much easier to start, test, package, and run in compact environments; PostgreSQL connects it to another mature production database ecosystem. The remaining Core, installer, content, security, and MCP improvements make QUIQQER 2.31 a substantial foundation release rather than a routine collection of maintenance changes.