What 'PHP / Laravel CRM' typically means in Indian SMBs
Walk into a hundred Indian SMBs running custom CRMs and the single most common backend pattern is PHP on MySQL. The variations are predictable and almost all of them connect cleanly through standard database credentials.
- Vanilla PHP or CodeIgniter (2010 - 2017). Often built by a freelancer or small local agency, deployed on a single LAMP server in a Mumbai or Hyderabad data centre. Schema conventions vary widely, naming is rarely consistent.
- Laravel 7 - 11 (2018 onwards). Built either in-house or by a slightly larger development shop, deployed on a VPS or AWS Lightsail. Eloquent conventions provide some predictability.
- MySQL or MariaDB backend. Almost universal. Occasionally PostgreSQL when the original developer had stronger database opinions.
- Schema size from 30 to 300+ tables. A simple lead capture system might have 30 tables. A CRM that has accumulated features for a decade might have several hundred.
What unites all of these is that the data is in a standard database accessible via standard credentials. That is all KolossusAI needs to start reading.
Reading the underlying MySQL or MariaDB directly
The connection is identical to any other MySQL or MariaDB read. Create a user with SELECT permission on the database (or specific tables), grant it from the IP range KolossusAI will connect from, and we are reading. Performance is excellent - typical mid-market Indian CRM databases of 5 to 50 GB run analytics queries in well under a second on modest hardware.
We support all current and recent versions: MySQL 5.7 through 8.x, MariaDB 10.3 onwards. Older databases (MySQL 5.5 or 5.6) work too with minor connector adjustments, which matters because some long-running Indian SMB CRMs are still on these versions and the upgrade path has not been a priority.
We do not need credentials for the Laravel application itself. Direct database access with a read-only role is sufficient and is the cleanest pattern from both a security and a maintenance perspective. If you ever rebuild the front-end, the analytics layer keeps working unchanged.
Connection security model
The default we recommend for Indian SMB Laravel deployments is a dedicated read-only database user with three layered restrictions, plus network and audit controls.
- SELECT only. No INSERT, UPDATE, DELETE, or schema-modifying privileges. The role cannot change your data even if compromised.
- Application schema only. No access to the mysql or information_schema beyond what is needed for introspection. The role sees only what your CRM uses.
- IP-restricted credentials. Restricted to the connector's source range so even leaked credentials cannot be used from anywhere else.
- Network isolation options. SSH tunnel through a jump host, or fully on-premise deployment inside your network so no external traffic is involved at all. Both are common patterns.
- Two independent audit logs. KolossusAI logs every query, user, and result internally. MySQL or MariaDB's general log records every query against the read-only user from the DB side. The two logs should agree, a useful integrity check during the first audit.
Eloquent conventions and field naming patterns
Laravel applications using Eloquent (the framework's ORM) tend to follow consistent patterns that KolossusAI knows to look for. The implication for analytics is that a Laravel CRM has more predictable shape than a vanilla PHP one - we can detect relationships, infer joins, and propose vocabulary mappings much faster.
- Plural snake_case table names. 'users', 'deal_stages', 'company_contacts'. Predictable enough that schema discovery completes one to three days faster than on equivalent vanilla PHP.
- Singular_id foreign keys. 'user_id', 'deal_id'. KolossusAI can auto-detect relationships from naming alone in most cases.
- created_at and updated_at timestamps. Auto-populated on most tables. Useful for time-window queries without any schema work.
- Accessors and mutators in PHP. Eloquent models often compute derived fields ('days since last contact', 'deal velocity') in PHP rather than storing them. The screen value may not exist as a column - we compute equivalents at query time using the underlying timestamp fields, which is fine but worth understanding during the first week.
Soft deletes, timestamps, and other Laravel quirks
Laravel's soft delete pattern adds a deleted_at column to tables that opt in. Rows with deleted_at IS NOT NULL are considered deleted by the application and filtered out of normal queries. KolossusAI respects this by default - "show me all deals" returns only non-deleted rows. If your team ever wants to query soft-deleted history ("how many leads did we soft-delete in the last quarter and why"), the AI can include them with an explicit ask.
Timestamps in Laravel default to UTC in the database when configured correctly, but in practice many Indian SMB deployments store local time (IST) without a timezone column. We detect this during onboarding by comparing known event timestamps to user-reported times and apply the correct offset thereafter. Mixed timezone tables (some columns in UTC, some in IST) are common in older systems and we handle them column by column.
Other quirks worth knowing: Laravel migrations sometimes leave orphaned columns from older feature iterations, the jobs and failed_jobs tables can grow huge, and the sessions table is often not what you want to query for "active users". KolossusAI's onboarding flags these and excludes the noise from default analytics scope.
Multi-tenant Laravel patterns
Multi-tenant Laravel CRMs come in two main flavours, with a third occasional pattern. The choice between them is yours and KolossusAI adapts to whichever one your CRM uses.
| Single-DB multi-tenant | DB-per-tenant | |
|---|---|---|
| Pattern | tenant_id column on every tenant-scoped table | Each customer gets their own MySQL database |
| Pros | Simpler ops, one connector, lower cost | Stronger isolation, true cross-tenant impossibility |
| Cons | Tenant filter must be enforced on every query | Heavier admin, one connector per tenant DB |
| How KolossusAI handles it | Replicates the tenant_id filter automatically once mapped | One connector per tenant, separate analytics scopes |
| Right default for | Most SMB SaaS CRMs | Highly regulated tenants |
Two anonymised examples from Indian SMB deployments
A Pune-based industrial equipment distributor runs a Laravel 9 CRM their internal team built over four years. About 180 tables, 4 GB of data, multi-tenant with tenant_id across all tables. Onboarding took eight working days end to end. The unlock was cross-querying their CRM and Tally to answer "which customers have outstanding above 60 days AND no recent CRM contact" - previously a multi-hour monthly Excel exercise, now a one-line question.
A Bengaluru-based EdTech ran a CodeIgniter CRM from 2014 alongside a newer Laravel build for a different vertical. Two databases on the same MySQL instance, different schemas, different naming conventions. We onboarded both as separate connectors, mapped the shared customer concept across them, and built a single vocabulary covering both. Total time: three weeks across both systems. The founder's most-asked question, "compare conversion across our two product lines weekly", went from impossible to a standard report.
Both of these deployments are still using their original CRM applications unchanged. KolossusAI is purely additive - the existing application keeps doing what it does, and the analytics layer rides on the same data.
What the integration physically takes
From your side: about an hour of your developer's time to create the read-only MySQL user and grant the permissions, another hour or two during week one to label any cryptic tables we ask about, and access to one technical person for occasional questions during the three-week onboarding. No code changes to your CRM. No new tables. No schema migrations. See AI Analytics for Custom CRMs for the full pattern.
From our side: connector configuration, schema discovery, vocabulary mapping with your team, user account setup, and the first month of validation. The 14-day POC covers everything except the broader rollout, and is free with no credit card. See all connectors.
Infrastructure: zero new infrastructure on your side if you go with managed cloud (we handle everything except the read-only role). One additional server or VM if you choose on-premise deployment, sized for your team count. Either way, no impact on the running CRM application.