Version: 1.1.0Documentation Index
Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt
Use this file to discover all available pages before exploring further.
Date: 2026-01-17 (Updated)
Status: ✅ Phase 1 Complete
Database: PostgreSQL 15 (Supabase)
Executive Summary
This document reviews currently installed PostgreSQL extensions and provides recommendations for additional extensions that would benefit the Encore Health OS platform based on:- Current extension usage patterns
- Codebase analysis (full-text search, ILIKE queries, JSONB operations)
- Multi-tenant healthcare ERP requirements
- Performance optimization needs
- ✅ 10 extensions currently installed (pgcrypto, pg_stat_statements, pg_net, pg_cron, uuid-ossp, pg_graphql, pgmq, pg_trgm, unaccent, btree_gin)
- ✅ 3 high-priority extensions enabled (pg_trgm, unaccent, btree_gin) - Phase 1 Complete
- 📊 2 medium-priority extensions for future optimization (pg_partman, pg_jsonschema)
- 🔍 Full-text search patterns optimized - trigram indexes added
Currently Installed Extensions
| Extension | Version | Schema | Purpose | Status |
|---|---|---|---|---|
pgcrypto | 1.3 | extensions | Cryptographic functions (SSN encryption, password hashing) | ✅ Active |
pg_stat_statements | 1.11 | extensions | Query performance monitoring | ✅ Active |
pg_net | 0.19.5 | extensions | Async HTTP requests from database | ✅ Active |
pg_cron | 1.6.4 | pg_catalog | Job scheduler for scheduled tasks | ✅ Active |
uuid-ossp | 1.1 | extensions | UUID generation | ✅ Active |
pg_graphql | 1.5.11 | graphql | GraphQL API support | ✅ Active |
pgmq | 1.5.1 | pgmq | Lightweight message queue | ✅ Active |
supabase_vault | 0.3.1 | vault | Supabase Vault Extension | ✅ Active |
pg_trgm | 1.6 | public | Trigram text search | ✅ NEW |
unaccent | 1.1 | public | Accent-insensitive search | ✅ NEW |
btree_gin | 1.3 | public | GIN indexes for standard types | ✅ NEW |
High-Priority Recommendations
1. pg_trgm - Trigram Text Search ⭐⭐⭐
Priority: HIGHImpact: Performance improvement for text search
Effort: Low (enable extension, add indexes) Why:
- Current Pattern: Extensive use of
ILIKE '%pattern%'queries (found 25+ instances) - Problem: ILIKE with leading wildcards cannot use indexes efficiently
- Solution: Trigram indexes enable fast fuzzy text matching
hr_employees(name, job_title searches)hr_positions(title searches)pf_documents(title, content searches)fw_workflow_templates(name, description searches)it_knowledge_base_articles(title, content searches)- All tables with full-text search indexes
- Before: Sequential scan on ILIKE queries (slow on large tables)
- After: Index scan with trigram matching (10-100x faster)
- Storage: ~30% of indexed column size (acceptable trade-off)
- Enable extension in migration
- Add trigram indexes for high-traffic search columns
- Update search queries to use
%operator orsimilarity()function - Monitor query performance improvement
2. unaccent - Accent-Insensitive Search ⭐⭐⭐
Priority: HIGHImpact: Better user experience for name searches
Effort: Low (enable extension, update indexes) Why:
- Healthcare Context: Names often contain accents (José, François, etc.)
- Current Problem:
ILIKEsearches won’t match “Jose” when searching for “José” - Solution: Unaccent extension removes accents for search
hr_employees(first_name, last_name)pf_profiles(first_name, last_name)rh_residents(first_name, last_name)- Any table with person names
- Minimal overhead (unaccent is fast)
- Significantly better search results for international names
3. btree_gin - GIN Indexes for Standard Types ⭐⭐
Priority: HIGHImpact: Better JSONB query performance
Effort: Low (enable extension, add indexes) Why:
- Current Pattern: 363 tables with
custom_fields JSONBcolumns - Problem: Standard GIN indexes on JSONB can be large
- Solution: btree_gin allows composite indexes mixing JSONB with other types
- Faster queries filtering by organization_id + custom_fields
- Smaller indexes than separate GIN indexes
- Better query planning for multi-tenant queries
4. pg_partman - Table Partitioning ⭐⭐
Priority: HIGH (Future)Impact: Performance for large audit/log tables
Effort: Medium (requires planning and migration) Why:
- Data Archival Plan: Identified need to archive old audit logs, activity logs
- Problem: Large tables (audit logs, workflow executions) will slow down over time
- Solution: Partition tables by date for easier archival and better query performance
pf_audit_logs(partition bycreated_atmonthly)pf_activity_logs(partition bycreated_atmonthly)fw_workflow_executions(partition bycreated_atmonthly)pf_notifications(partition bycreated_atmonthly)
- Query Performance: Faster queries on recent data (only scan relevant partitions)
- Maintenance: Easy to drop old partitions (vs. DELETE operations)
- Storage: Better compression and index efficiency per partition
- Review data archival plan (
docs/migration/DATA_ARCHIVAL_PLAN.md) - Plan partition strategy (monthly vs. quarterly)
- Test partitioning on staging environment
- Migrate production tables during maintenance window
5. pg_jsonschema - JSONB Validation ⭐
Priority: MEDIUMImpact: Data quality for custom_fields
Effort: Low (enable extension, add check constraints) Why:
- Current Pattern: 363 tables with
custom_fields JSONB DEFAULT '{}' - Problem: No validation of JSONB structure (could store invalid data)
- Solution: Validate custom_fields against JSON Schema
- Minimal (validation only on INSERT/UPDATE)
- Prevents invalid data from being stored
- Better data quality for reporting
- May be too restrictive if custom_fields structure varies significantly
- Consider making validation optional per organization
Medium-Priority Recommendations
6. citext - Case-Insensitive Text Type
Priority: MEDIUMImpact: Simpler queries (no need for LOWER()/UPPER())
Effort: Low (enable extension, migrate columns if desired) Why:
- Many queries use
LOWER(column) = LOWER(value)orILIKE citexttype handles case-insensitivity at the type level
- Not recommended for existing tables (would require column type changes)
- Consider for new tables where case-insensitivity is required
- Current ILIKE pattern is acceptable and doesn’t require migration
7. ltree - Hierarchical Tree Structures
Priority: MEDIUM (If Needed)Impact: Efficient tree queries
Effort: Medium (requires schema changes) Why:
- Could be useful for organizational hierarchies, category trees
- More efficient than recursive CTEs for tree queries
- Only if tree structures are needed
- Current patterns don’t show hierarchical data requirements
- Defer until needed
8. tcn - Triggered Change Notifications
Priority: MEDIUMImpact: Event-driven workflows
Effort: Low (enable extension, add triggers) Why:
- Current Pattern: Event-based integration for workflows (FW-16)
- Problem: Manual event publishing via triggers
- Solution: Automatic change notifications via tcn extension
- May duplicate existing event publishing logic
- Review FW-16 event integration patterns before implementing
- Defer until event system review
Low-Priority / Not Recommended
Extensions to Avoid
| Extension | Why Not Recommended |
|---|---|
hstore | JSONB already used throughout codebase |
moddatetime | Custom triggers already handle updated_at |
fuzzystrmatch | pg_trgm provides better fuzzy matching |
pgroonga | Full-text search already implemented with native PostgreSQL |
vector | No AI/ML use cases identified in codebase |
Implementation Plan
Phase 1: Immediate (Week 1-2) ✅ COMPLETE
Priority Extensions (All Enabled 2026-01-17):- ✅ pg_trgm - Enabled with trigram indexes for high-traffic search columns
- ✅ unaccent - Enabled with unaccented search indexes for name columns
- ✅ btree_gin - Enabled for composite index optimization
- Verify search performance improvement
- Test accent-insensitive searches
- Monitor index sizes
Phase 2: Optimization (Month 2-3)
Conditional Extensions: 4. pg_jsonschema - If custom_fields validation is needed 5. pg_partman - If audit/log tables exceed 1M rows Decision Criteria:- Monitor table sizes monthly
- Review data archival plan progress
- Assess custom_fields data quality issues
Phase 3: Future (As Needed)
Deferred Extensions: 6. citext - For new tables requiring case-insensitive text 7. ltree - If hierarchical data structures are needed 8. tcn - If event system review recommends itMigration Script Template
Performance Monitoring
Before/After Metrics
Track these metrics after enabling extensions:-
Search Query Performance:
-
Index Sizes:
-
Index Usage:
Rollback Plan
If extensions cause issues:References
Project Documentation
- Performance Recommendations:
docs/migration/SUPABASE_PERFORMANCE_RECOMMENDATIONS.md - Data Archival Plan:
docs/migration/DATA_ARCHIVAL_PLAN.md - Search Framework:
specs/pf/specs/PF-57-search-filter-sort-framework.md - Database Schema:
docs/architecture/DATABASE_SCHEMA.md
External Resources
- pg_trgm Documentation: https://www.postgresql.org/docs/current/pgtrgm.html
- unaccent Documentation: https://www.postgresql.org/docs/current/unaccent.html
- btree_gin Documentation: https://www.postgresql.org/docs/current/btree-gin.html
- pg_partman Documentation: https://github.com/pgpartman/pg_partman
Summary
Recommended Extensions (Priority Order):- ✅ pg_trgm - HIGH - Fast fuzzy text search (replaces slow ILIKE)
- ✅ unaccent - HIGH - Accent-insensitive name searches
- ✅ btree_gin - HIGH - Composite indexes for JSONB + standard types
- ⏳ pg_partman - HIGH (Future) - Table partitioning for large audit logs
- ⏳ pg_jsonschema - MEDIUM - JSONB validation (if needed)
- Search Performance: 10-100x faster text searches
- User Experience: Better search results (accent-insensitive, fuzzy matching)
- Database Performance: Better index utilization, smaller query times
Last Updated: 2026-01-16
Status: Ready for Implementation
Next Steps: Create migration script for Phase 1 extensions