Senior Full-Stack / Database Performance Engineer – Scale Existing SaaS Platform

We are looking for a senior engineer/architect to take an existing production SaaS platform and prepare it for significant scale. The platform is already functional and in use by multiple happy clients. We now need to support clients processing millions of transactions per year while keeping operational screens, integrations and analytics fast and responsive. This is primarily an architecture, database, infrastructure and performance project — with no frontend work. Current Stack: Frontend: * React * Modern component patterns * Real-time state management * API-driven data fetching **Backend** * Node.js * Express * Business logic and server-side processing * Third-party APIs and integrations * AI-powered functionality * Local/hardware bridge integrations Current Database / Backend Services * PocketBase * SQLite * REST API * Real-time subscriptions * Authentication and role-based access * File storage The current data model contains multiple interconnected areas including: * Tenants / shops * Users and permissions * Products * Categories * Suppliers * Brands * Customers * Transactions and transaction lines * Orders * Stock levels and stock movements * Analytics snapshots * Rankings and pre-aggregated metrics * Sharing/access rules * Audit logs * Integration and mapping data The application is multi-tenant, with strict tenant/shop isolation. The Problem PocketBase/SQLite has worked well during development and early production, but it is not the architecture we want to rely on as data volume and client count increase. We had to turn down a couple of big clients as we know our current architecture cannot support the size of their operations. The system needs to comfortably handle: * Millions to tens of millions of transaction lines * Continuous transactional writes * Multiple concurrent users and devices * Large historical searches * Dashboards and analytics * Stock and operational workloads * Third-party API imports and syncing * Real-time or near-real-time updates * AI integrations * Hardware/local-device integrations * Background jobs and data processing Heavy analytics must not slow down live operational activity. --- Scope We need someone who can audit the current system, design the target architecture and implement the migration. 1. Database Architecture * Review the existing PocketBase collections and relationships * Properly map the current data model and dependencies * Design a scalable relational database structure * Likely migrate the main database to PostgreSQL * Preserve all existing data and relationships * Design appropriate primary keys, foreign keys, constraints and indexes * Optimise high-volume transaction and transaction-line storage * Review denormalisation vs normalisation where appropriate * Introduce partitioning where genuinely useful * Design scalable analytics/pre-aggregation structures * Preserve audit history and data provenance * Maintain strict tenant isolation * Create safe schema migration/versioning processes for future development We want a well-designed database, not simply the same PocketBase structure copied into PostgreSQL. 2. Performance & Analytics The platform combines live transactional workloads with analytical workloads. For example: A client may have 20 million transaction lines. Fifty tills may be actively submitting transactions while a few other users open a dashboard analysing 12 months of sales, margin, stock and product rankings. Both need to remain fast. The architecture should address: * Query optimisation * Index strategy * Pagination * Incremental aggregation * Pre-computed metrics * Caching * Background processing * Queues * Read replicas if appropriate * Analytics database/engine if genuinely required * Avoiding full historical scans for routine dashboards 3. API Architecture Review and improve the Node.js / Express API layer. This includes: * Clear API structure * Fast database access patterns * Consistent pagination/filtering * Validation * Authentication * Role/permission enforcement * Tenant isolation * Rate limiting where appropriate * Idempotent write operations * Reliable third-party integration handling * API versioning/migration strategy * Error handling and observability External integrations must be safe to retry without duplicating transactional data. 4. Third-Party Integrations & Data Mapping The platform connects to external systems and needs to map external data into its own internal model. We need a robust pattern for: * External IDs * Data-source provenance * Product/customer/transaction mappings * Import jobs * Incremental sync * Retry handling * Duplicate prevention * Conflict handling * Failed import visibility * Integration logging New integrations should be easy to add without rewriting the core platform. ### 5. Hardware / Local Bridges Parts of the platform communicate with local devices and hardware through bridge applications/services. Examples may include: * POS terminals * Receipt printers * Barcode printers * Payment terminals * Customer displays * Local Windows/Android services * Other shop hardware The cloud architecture must work cleanly with these local bridges. We need clear, stable contracts between: Frontend → Cloud API → Local bridge → Hardware The architect should understand reliability issues such as: * Device connectivity * Offline/reconnect behaviour * Retries * Idempotency * Duplicate commands * Status reporting * Device authentication * Secure communication 6. AI Integration The platform includes and will increasingly use AI functionality. We need an architecture where AI features can be added without tightly coupling them to the core transactional system. This may include: * LLM/API integrations * Structured AI outputs * Background AI jobs * Usage tracking * Prompt/version management * Failure/retry handling * Cost controls * Secure access to tenant data * Guardrails around AI-generated database actions AI should enhance the system without becoming a reliability dependency for core operations. 7. Hosting & Infrastructure The application will be moved to a more scalable production hosting setup. We need recommendations and implementation covering: * Application hosting * Managed PostgreSQL * Database connection pooling * Workers/background services * Redis/cache if needed * Object/file storage * Environment separation * Secrets management * SSL/security * Automated deployments * Monitoring * Logging * Performance metrics * Slow-query visibility * Backups * Point-in-time recovery * Disaster recovery * Capacity planning The hosting architecture should scale progressively rather than requiring expensive enterprise infrastructure from day one. --- VERY IMPORTANT: We Must Be Able to Continue Developing It This is one of the most important requirements of the project. We actively develop the application ourselves using modern AI-assisted / “vibe coding” workflows. After the architecture work is complete, with your support, we need to be able to continue adding: * Pages * Features * Database fields * Tables * APIs * Integrations * Analytics * AI functionality * Hardware features without needing to hire the architect again for every change. Therefore we strongly prefer: * Straightforward architecture * Conventional technologies * Clear folder structures * Consistent patterns * Minimal unnecessary abstraction * Minimal custom infrastructure * Good naming * Reusable API/database patterns * Schema migration tooling * Clear development and deployment workflows * Good documentation * Architecture diagrams * Examples/templates for adding new features * A simple local development setup We do not want clever architecture for the sake of clever architecture. If PostgreSQL + Node + a worker + Redis solves the problem, we would rather have that than ten microservices, Kubernetes and six specialist databases. The final system should be understandable by another competent developer — and by AI coding tools — without needing extensive institutional knowledge. --- Migration Requirements This is a live system. The migration must therefore include: * Full database mapping * Migration scripts * Data validation * Record-count/reconciliation checks * Relationship validation * Staged testing * Performance testing * Cutover plan * Rollback plan * Minimal downtime * Prevention of lost writes during migration * Post-migration verification PocketBase currently provides more than just SQLite, so the migration plan must explicitly address: * Database * Authentication * Permissions * Real-time subscriptions * File storage * Existing APIs --- Required Experience We are particularly interested in candidates with strong experience in: * PostgreSQL * Large transactional databases * Database/schema architecture * SQLite/PocketBase migrations * Node.js / Express * React applications * Multi-tenant SaaS * High-volume transactional systems * Analytics architectures * Query optimisation * Background workers and queues * Redis/caching * External API integrations * Data synchronisation * Hardware/device integrations * AI/LLM integrations * Cloud infrastructure * Monitoring and observability * Production migrations * Load testing Retail/POS experience is useful but not required. --- What We Want From Your Proposal Please do not send a generic full-stack proposal. Start your proposal with SCALE and answer these briefly: 1. What is the largest transactional database you have personally designed or worked with? 2. Have you migrated a live SQLite/PocketBase or similar system to PostgreSQL? How did you handle the cutover? 3. How would you structure a database containing tens of millions of transaction lines while keeping analytical dashboards fast? 4. How would you prevent analytics workloads from affecting live transactional workloads? 5. How would you structure third-party integrations so imports can retry safely without creating duplicates? 6. What would your preferred production hosting architecture look like for this type of application? 7. How would you handle communication between a cloud platform and local hardware/device bridges? 8. How would you integrate AI functionality without allowing AI workloads to affect the reliability of the core application? 9. How would you design the architecture so that a competent developer using AI-assisted coding can continue adding features without needing you? 10. What parts of the architecture would you deliberately keep simple? Please include examples of relevant projects, approximate data volumes, your exact role and measurable performance improvements where possible. We are looking for someone who can design the foundation, implement it and then leave us with a system we can confidently continue building ourselves along with your support. It's definitely a long term job - once the first migration is successful.