In un generico scenario dei client applicativi hanno la possibilità  di accedere ad un database, in lettura e scrittura, secondo le policy stabilite caso per caso. Il caso del database in cloud è progettato e concepito per ambienti informatici virtualizzati, sfruttando al meglio le risorse messe a disposizione, con evidenti vantaggi di economicità , risparmio di risorse e ore lavorative allocate al meglio. I database di questo ambito vengono, di fatto, sfruttati come servizi su richiesta, ed è questo che li rende DBaaS, di base.
Cambia ovviamente la struttura generale del database, rispetto a quello relazionale classico (es. MySQL), che non sarà  quindi più composto da insiemi di tabelle bensà¬ da tabelle distribuite su vari data center, a cui accedere in modo trasparente. Esistono, in sostanza, dei "nodi" distribuiti in vari punti del mondo, in teoria, a cui sarà  possibile accedere sfruttando opportune policy o protocolli. Ovviamente si possono sfruttare le connettività  da mobile e quelle da rete fissa per accedere a tali risorse, per cui pensiamo ad esempio ad un'app interna di Business Intelligence, che spesso dovranno archiviare enormi quantità  di dati - per loro stessa natura. Quello che succede è che una query, ovvero una richiesta di archiviare o richiedere dati secondo una certa "vista", viene elaborata da una parte del software, per poi essere distribuita al nodo oppure ai nodi di competenza. Ciò è tutt'altro che banale, in effetti: il nodo singolo potrebbe fungere da collo di bottiglia, ed ecco perchè è prevista la possibilità  di parallelizzare le operazioni sulla query mediante idonei split o divisione dei nodi. Anche le query, dal canto loro, si possono suddividere in task secondo opportuni protocolli (ed una solida base logico-matematica di fondo), portando alla costruzione di sistemi molto veloci, efficenti e complessi che costituito la logica di fondo di business intelligence.