RedBeanPHP: an ORM that invents your schema as you write

Four lines is the whole storage model

The quick example in the README is the project in miniature:

$book = R::dispense("book");
$book->author = "Santa Claus";
$book->title = "Secrets of Christmas";
$id = R::store( $book );

Four statements, and the README's own reaction to it is a flat assertion that it is that simple. Reading them closely tells you the design. `dispense` takes a bean type as a string and hands back an empty object of that type. Assigning a property that has never been set does not fail, because there is no class to fail against. `store` writes the object and returns its identifier.

The consequence of that sequence is the headline feature: tables and columns are created automatically as you go. There is no schema file, no migration tool and no deployment step that applies structural changes. The database grows to match what your code has already done, which means the first version of an idea can be running without anyone having written a data definition for it.

The README describes the tool as easy to use, and it lists three properties directly: automatic table and column creation, no configuration on a fire and forget basis, and no complicated package tools or autoloaders because there is only one file.

One file, and the recommended way to install it

That third point deserves more attention than it gets. RedBeanPHP installs by downloading an archive from redbeanphp.com/download, extracting it, and putting it in the PHP project. The README recommends this route and adds an optional step of checking a sha256sum and signature, which is a sensible thing to do with a dependency you are asked to commit into your own repository.

The Composer route exists but the README labels it not recommended, which is unusual enough to be worth reporting rather than smoothing over. Adding the package to composer.json looks like this:

{
    "require": {
        "gabordemooij/redbean": "dev-master"
    }
}

Note what that version constraint asks for. `dev-master` tracks the development branch rather than a tagged release, so a Composer install is not pinned to a version you have reasoned about. That is one plausible reason the maintainer steers people toward the archive.

The repository tree matches the one file claim. Alongside `RedBeanPHP/`, which holds the library itself, there is `composer.json`, the test harness with `run_all_tests.sh` and `run_single_test.sh`, a `test-dist.ini` configuration file, and two unusual root entries named `replica2.php` and `replica2-win.php` with a `p533patch.php` alongside them.

The namespace trap Composer introduces

The README spends more space on this than on anything else, which tells you how often it trips people up. Nearly every example on the RedBean website uses the `R` class directly. Under Composer, namespaced autoloading means the class is actually available as `\RedBeanPHP\R`, and if you want the short alias you have to import it yourself:

use \RedBeanPHP\R as R;

The same collision runs deeper into the model layer. The website's model examples extend `RedBean_SimpleModel`, but under Composer you must extend `SimpleModel` and declare its namespace, which is why the README spells out a complete example rather than a fragment:

use \RedBeanPHP\R;

class User extends \RedBeanPHP\SimpleModel
{
    ...
}

The README then notes the extra step this forces: even inside the model you still need the `use \RedBeanPHP\R` statement so the `R::` shortcut resolves. This is the price of Composer integration, and it is the clearest argument for the download route, where none of it applies because the class really is named `R`.

Release history and what changed in 5.7

Version 5.7.6 was published on 2026-04-30 and its notes are short: compatibility fixes for PHP 8.5, and a change to the Tag Manager so it also accepts Simple Models rather than only OODBBeans. The PHP version compatibility note is the useful signal there, because it means the project is keeping pace with new PHP releases, and 5.7.5 from 2025-05-29 also improved error messages for bean types and added a `SimpleModelInterface`.

Going back further, 5.7.4 was published on 2023-03-17 under the name 5.7.4 Jubilate Sunday Edition. Its notes cover PHP 8.2 compatibility, a fix to `R::transaction()`, making `runQuery()` public and optimising it, and support for `DateTimeInterface`. Two years separate that release from 5.7.6, which suggests a maintenance rhythm rather than a feature sprint cadence.

The project is not archived and the last push was on 2026-07-09. With only 3 open issues on a repository with 2,313 stars, the low issue count is worth reading as a signal about how much attention the codebase currently needs, rather than as evidence of suppression.

What you give up by skipping migrations

Automatic schema creation is a good trade in the first hour of a project and a bad one in the third year, and RedBeanPHP makes that trade explicitly. There is no migration history in the repository, no versioning of schema changes, and nothing that records what the database looked like on a given date. When a column changes meaning, the code changes and the database follows.

That approach has real advantages. Prototypes do not need a schema design step, small scripts stop being database projects, and a bug fix is a code change rather than a code change plus a migration to run in the right order. It also means you can prototype an API in a way that feels like writing to a dictionary.

The costs land later. Reporting tools that assume known column types have less to go on, because the type inference is the ORM's decision rather than yours. And a second developer reading the code sees bean property assignments rather than a declarative model, which is a weaker signal about intended structure. None of this makes the library wrong; it makes it a choice that fits unevenly across a project's lifetime.

The README does not discuss migrations at all, and there are no files in the tree related to them. Whatever documentation exists on that subject, if any, is on the website, which the README names as the place for further information.

Editorial conclusion

RedBeanPHP solves a specific and unglamorous problem: getting data into a database before you have decided what the data looks like. It does that with one file, no configuration and no migrations, and the four line store pattern is short enough to teach in a paragraph. The trade is that your schema then lives in your code as bean property assignments rather than in a versioned migration history, which suits prototypes and small tools more than it suits a system whose data model others depend on. If you take that route, start from the downloaded archive rather than Composer, since the namespace difference is the part that catches people out, and read the models page on the website before building your first bean class.

Frequently asked questions

Official sources

1. gabordemooij/redbean on GitHub
2. Issues
3. Project website
4. README
5. Releases