Available Types

pgvector Types

The vector, halfvec, and sparsevec types use the length column option to specify the number of dimensions:

use Doctrine\ORM\Mapping as ORM;
use MartinGeorgiev\Doctrine\DBAL\Types\ValueObject\Sparsevec;

#[ORM\Entity]
class Embedding
{
    // VECTOR(1536) — fixed 1536-dimensional float vector
    #[ORM\Column(type: 'vector', length: 1536)]
    private array $embedding;

    // HALFVEC(1024) — half-precision float vector
    #[ORM\Column(type: 'halfvec', length: 1024)]
    private array $smallEmbedding;

    // SPARSEVEC(4096) — sparse vector with up to 4096 dimensions
    #[ORM\Column(type: 'sparsevec', length: 4096)]
    private Sparsevec $sparseEmbedding;
}

Important: Omitting length produces a dimensionless column (VECTOR with no size), which is valid DDL but cannot be indexed with HNSW or IVFFlat indexes. Always specify length for production use.

Bit String Types

The bit and bit varying types support an optional length parameter via column attribute:

use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity]
class Permissions
{
    // BIT(1) — fixed single bit (default when no length specified)
    #[ORM\Column(type: 'bit')]
    private string $active;

    // BIT(8) — fixed 8-bit flags
    #[ORM\Column(type: 'bit', length: 8)]
    private string $flags;

    // BIT VARYING — unlimited length (default when no length specified)
    #[ORM\Column(type: 'bit varying')]
    private string $mask;

    // BIT VARYING(64) — variable length, up to 64 bits
    #[ORM\Column(type: 'bit varying', length: 64)]
    private string $features;
}

Important: BIT without a length defaults to BIT(1) in PostgreSQL, which stores exactly one bit. Use BIT VARYING for variable-length bit strings, or specify an explicit length with BIT(n).

UUID Array Type

The uuid[] type validates UUID format and returns string[] rather than UUID value objects. This design decision keeps the library lightweight and framework-agnostic:

• No additional dependencies - Works without requiring ramsey/uuid or symfony/uid
• Consistent with other array types - Follows the same pattern as TextArray, IntegerArray, etc.
• Framework agnostic - Compatible with any UUID library of your choice

If you need UUID objects, you can easily convert the strings:

// With ramsey/uuid
use Ramsey\Uuid\Uuid;
$uuids = array_map(fn(string $uuid) => Uuid::fromString($uuid), $entity->getUuidArray());

// With symfony/uid
use Symfony\Component\Uid\Uuid;
$uuids = array_map(fn(string $uuid) => Uuid::fromString($uuid), $entity->getUuidArray());

Money Type

The money type maps PostgreSQL's money data type and returns locale-formatted strings (e.g. $1,234.56). PostgreSQL formats money values according to the server's lc_monetary locale setting, so the exact output format depends on your database configuration.

Important considerations:

• PostgreSQL's money type does not store currency information — the currency symbol is purely a formatting artifact of the server locale
• If you need multi-currency support, consider using numeric with application-level currency handling instead
• Values written to the database must contain at least one digit; full format validation is deferred to PostgreSQL

If you need rich money objects for arithmetic or multi-currency support, you can convert the string after retrieval:

// With moneyphp/money (requires parsing the locale-formatted string)
use Money\Money;
use Money\Currency;
$amount = (int) round((float) preg_replace('/[^0-9.\-]/', '', $entity->getPrice()) * 100);
$money = new Money($amount, new Currency('USD'));

// With brick/money
use Brick\Money\Money;
$money = Money::of(preg_replace('/[^0-9.\-]/', '', $entity->getPrice()), 'USD');

Note that both examples above assume USD — you must know the currency independently since PostgreSQL does not store it.

Hstore Type

The hstore type requires the PostgreSQL hstore extension. Enable it with:

CREATE EXTENSION IF NOT EXISTS hstore;

It maps to array<string, string|null> in PHP. Keys and values are always strings; a NULL value in hstore is represented as null in PHP.

Citext Type

The citext type requires the PostgreSQL citext extension. Enable it with:

CREATE EXTENSION IF NOT EXISTS citext;

It is a case-insensitive text type: comparisons are case-insensitive in PostgreSQL while the original casing of values is preserved. It maps to string in PHP and behaves identically to text for storage and retrieval — the difference is purely in how PostgreSQL evaluates equality and ordering.

Use citext when you want case-insensitive lookups (e.g. usernames, email addresses) without lowercasing values on write.