Tietokannat ovat datan ja informaation varastointiratkaisuja. Kannat palvelevat lukuisia eri käyttötarpeita ja niitä voidaan pystyttää itse tai ostaa valmiina pilvipalveluna.

Kun kaikkia ominaisuuksia ei voi saada samassa paketissa, kehitystiimin haasteeksi jää valita sopivin kompromissi datan sijoituspaikaksi. Valintaa tehdessä tulee ottaa huomioon lukuisia seikkoja, kuten datan formaatti, datan luku- ja kirjoitusintensiivisyys sekä ratkaisun budjetti. Yhden vaihtuvan numeron - esimerkiksi viimeisin lämpötila ilman historiatietoja - tallennukseen voi riittää yksinkertainen kirjoitus tiedostoon. Taulukkomaiseen dataan, jossa on relaatioita muihin taulukoihin, voi toimia perinteinen SQL-kyselykieltä tukeva relaatiokanta, kuten PostgreSQL. Entäpä jos data sisältää runsaasti mielivaltaisia relaatioita? Tällöin datasi muodostaa graafin ja oikea ratkaisukin voi löytyä graafikannoista, kuten neo4j tai Amazon Neptune.

Tarvitsetko datatallennuksillesi ACID -periaatteet toteuttavan transaktiotuen, eli mahdollisuuden toteuttaa useampi tietokantaoperaatio atomisena ja mahdollisuutena peruuttaa kaikki transaktion sisäiset operaatiot yhdenkin operaation epäonnistuessa? Hyvinkin eri tyyppiset kannat voivat tukea transaktioita. Mikropalveluarkkitehtuurissa saatat joutua simuloimaan epätäydellistä transaktiotukea arkkitehtuuritasolla, sillä arkkitehtuurin mukaisesti mikropalvelut sisältävät yleensä omat tietokantansa, eikä niiden välinen aito transaktiotuki ole mahdollista.

Erityisempiin datatarpeisiin saatat tarvita juuri tiettyyn tarkoitukseen suunnitellun tietokannan. Niin kutsuttuja “purpose built” -tietokantoja saatat tarvita esimerkiksi IoT-laitteen tuottamalle datalle, jollainen on esimerkiksi AWS Timestream. Lohkoketjumaiseen dataan saattaisi sopia puolestaan Amazon Quantum Ledger Database.

Omia datatarpeita voi kartoittaa laatimalla käyttöskenaarioita esimerkiksi käyttäjätarinoiden (engl. user story) avulla ja kartoittaa, miten skenaariot dataasi käsittelevät. Joihinkin tietokantoihin joudut suunnittelemaan myös erillisiä indeksejä hakujen optimoimiseksi. Haku, jonka tulokset saa aluksi jouhevasti, voi hidastua merkittävästi datamäärän kasvaessa ilman sopivaa indeksointia. Mitkä datan varastointi-, kirjoitus- ja hakutarpeesi ikinä ovatkaan, ratkaisua ei kannata toteuttaa hutaisten, sillä järjestelmään jo integroidun, vääräksi havaitun kannan vaihtaminen toiseksi voi olla työlästä ja siten kallista.