Grafana: Grafana 2.0: SQL Data source

I would personally suggest some thing more in the line of Cassandra (CQL) or SparkSQL

Wow, this us very usefull.

• add a array of db servers for loadbalancing
• a field that concatenate a LIMIT X to the query
• a switch for ORDER BY ASC DESC
• chose db columns for TIME and for VALUE from mysql table ?

@phagedorn some like that, not sure about the switch for order asc/desc, grafana always wants them in ascending order (by time). not sure about the limit x either.

more like a metric query template (written by user when they add the data source), this just an example, have not thought about this much yet.

SELECT MyValue as Value, Timestamp as Time 
  FROM MyMetrics
  WHERE SeriesName IN (?SeriesList) AND Time > (?TimeFrom) AND Time < (?TimeTo)
  ORDER BY Timestamp ASC 

@syepes I thinking as first step to implement something simple. Could you describe more what it would take to implement CQL or SparkSQL on top of a generic SQL database and what benefits? SparkSQL looks interesting from analaytics standpoint, any golang implementation?

+1 for allowing raw SQL

@torkelo : Query templates sounds nice :+1:
Would work for me for existing tables

Will this datasource has a suggestion editor? What DB backends for this datasource can be used ?

also interested in allowing raw SQL

Initially mysql and postgres, no auto complete isn't going to be included initially

interested +1

:+1: for postgres

:+1: for postgres

:+1: for postgres with JSON type

:+1: for postgres with JSON type

Any idea about the roadmap when SQL datasource will be available? In 2.0 or 2.1?

@juliusloman not sure, maybe in 2.2 or 2.3, so much other stuff that was pused to 2.1 that needs to happen first

But a PR is always welcomed

Having a SQL data source will definitely make grafana a top analytic tool. I would love to see it. Torkel, sorry not familar with github, what does PR entail?
+

@hceylan97 it entails that someone tries implement it and submits it as pull request (i.e feature patch), I would love to implement this, but not sure when I will have to do it as I will probably have more high prio issues for the next couple of months

besides you, curious if anybody else is working on this?

:+1:

+1 mysql

@torkelo I might start a PR for this pending the expected amount of work. Would love to figure out how to make new datasources so we can integrate more into Grafana. Could you give a rundown of what needs to be done to add a new data source and the work remaining for generic SQL support?

+1 Oracle

+1 MS SQL

:+1: for postgres with JSON type

+1 postgres / postgres with JSON type

@torkelo pinging again as this has been pushed back two months. I'd like to add some support for new datasources in Grafana and I'd love a rundown of how to do so and what is left for generic SQL support (pretty sure you'd appreciate if I could get a PR out too :))

@agilgur5 no work has been done on this yet

@torkelo what about d0d995d? In any case a rundown would be much appreciated

@agilgur5 that was mostly work on the data source plugin system nothing specific to a SQL data source

+1 MS SQL !!!

with MySQL in front you can insert in any SGBD with engine XA & Connect !

specify a metric query template (basically a SQL query with params)
specify a annotation query template

i wonder if this is needed? maybe it's extra hassle we can avoid.
isn't it sufficient to specify the table and columns when using the DS ? or perhaps specify the table in the DS so you only need to specify columns when using it. i do suspect there will be many tables with each only a few columns.

What's the ETA for this?

@EliSnow https://github.com/grafana/grafana/milestones says around September 29th. This feature alone might be done before that, and there's also the possibility it gets pushed back (as it has been a few times already). Regardless, I don't believe any work will be done on this until after the 2.1 release.

+1 MS SQL; +1 query with parameters
Actually why i'm asking. The simplest way to put perf counters to the scene from numerous windows boxes is to configure data collectors on them to put data directly to ms sql without any "middle ware collectors". So it would be really great to have an option jut to read that data from MS SQL. So this would be a really great option!

+1 - Postgres.

Postgres is just a phenomenal DB. If I have time, I might look into this @torkelo

@torkelo, I'd like to contribute to getting this done. I'm looking at the commit referenced earlier for the datasource plugin system (d0d995d). Is there any documentation for the plugin system? What pieces are needed? Looking at other datasources in the /public/app/plugins/datasource directory it appears to just be Javascript (Angular + AMD) and some HTML templates. Is there any Go code required to get this working or is it strictly Javascript?

Since SQL databases usually don't have a http api there will hävt to be some backend go code

+1 MySQL & Cassandra

This is somewhat off topic, but I think a good step (or alternative step) towards getting a SQL data source. It would be great to allow an admin user, from the UI, to add a custom HTTP data source.

The admin user could specify the base url and a javascript function which transforms a query into an actual http request. They could also provide javascript mapping function(s) which would transform the data returned from the http request into a common format understood by grafana. Eventually, there could be an interface for people to build their own UI query builder which could allow for hinting and such. One of the most important pieces of this is it has to be well documented.

Why is this relevant to this issue? Some people may elect to have their SQL database accessible through an HTTP endpoint rather than allow direct access. Perhaps grafana is not on the same network as the database and it has no direct access for security reasons. Even if the database is directly accessible and the user could provide raw SQL, there is still the issue that given an arbitrary SQL query, grafana is not going to know what format the data is returned in, and the javascript mapping functions will still be required (perhaps at the graph/dashboard level).

To avoid XSS perhaps we don't want any non-admin user to edit a dashboard and provide javascript functions which will be executed on the page. This could be avoided by requiring that SQL queries return data in a specified format. Alternatively, XSS perhaps could be mitigated through CSP.

I recognize that a determined person can currently add a custom HTTP data source by editing the source code, but this is more challenging because: 1) it's not documented (that I'm aware of), and 2) it requires different people to be involved, assuming a person's in a position where the roles "devops" and "grafana admin" are fulfilled by different people.

I personally was able to add a custom SQL data source through an HTTP endpoint which mimicked the influxdb interface. The query builder allows the user to specify arbitrary queries, I just needed to make sure my endpoint returned data in a format like influxdb. It's great, but it's hacky and leaves a lot to be desired.

Thoughts, @torkelo?

@EliSnow - Would you mind sharing the code?

@roybass, I am guessing you are asking about my code which mimics the InfluxDB interface.

I cannot share my specific code, and it probably wouldn't be very helpful if I did because it is specific to the language I used (Node.js), my database (Postgres), and the structure of my data (jsonb). The gist of what you need to do is create a /query HTTP endpoint which returns data in the same format that InfluxDB does.

Grafana will call your endpoint using the GET method with the q parameter of the query string being the search query/queries specified in your dashboard panel. Each query is delimited by a newline character. (Note: that the "Test Connection" button for testing your Data Source in the admin interface will send the query SHOW MEASUREMENTS LIMIT 1. If you return a 204 for that query that will suffice). You can design the search query to be your own DSL. I made my search query a simple JSON object. While you certainly could use real SQL for your search query, you should make sure the database user executing the query only has permission to SELECT on specific table(s). For me, my SQL queries are pretty long and gnarly, and I prefer to have a level of abstraction from the database.

InfluxDB returns data in the following [annotated] json format:

{
//each entry in "results" represents the result of a single query
  "results": [{
    // each entry in "series" represents a different group if the
    // query had a GROUP BY clause.
    "series" : [
      {
        "name" : "measurement name",
        // not sure which tags influx chooses to return
        // perhaps only the ones in the WHERE clause
        // grafana allows you to use tags in the alias pattern
        "tags" : {
          "foo" : "bar"
        },
        // I have not checked grafana's source but it's possible
        // it does not read the "columns" array
        "columns" : ["time", "mean"],
        "values" : [
          // time (in epoch ms), value
          [1442953067791, 41.2]
        ]
      }
    ]
  }]
}

If you don't have your own InfluxDB instance up and you need to play around with how Grafana sends it queries, you can use the test dashboard and your developer tools to take a peek.

As a disclaimer, I've probably missed something in how Grafana communicates with InfluxDB, but the above was enough to get me started.

Hope that helps.

Thanks! That's exactly what I meant

On Tue, Sep 22, 2015 at 11:57 PM, EliSnow [email protected] wrote:

@roybass https://github.com/roybass, I am guessing you are asking about
my code which mimics the InfluxDB interface.

I cannot share my specific code, and it probably wouldn't be very helpful
if I did because it is specific to the language I used (Node.js), my
database (Postgres), and the structure of my data (jsonb). The gist of what
you need to do is create a /query HTTP endpoint which returns data in the
same format that InfluxDB does.

Grafana will call your endpoint using the GET method with the q parameter
of the query string being the search query/queries specified in your
dashboard panel. Each query is delimited by a newline character. (Note:
that the "Test Connection" button for testing your Data Source in the admin
interface will send the query SHOW MEASUREMENTS LIMIT 1. If you return a
204 for that query that will suffice). You can design the search query to
be your own DSL. I made my search query a simple JSON object. While you
certainly could use real SQL for your search query, you should make sure
the database user executing the query only has permission to SELECT on
specific table(s). For me, my SQL queries are pretty long and gnarly, and I
prefer to have a level of abstraction from the database.

InfluxDB returns data in the following [annotated] json format:

{//each entry in "results" represents the result of a single query
"results": [{
// each entry in "series" represents a different group if the
// query had a GROUP BY clause.
"series" : [
{
"name" : "measurement name",
// not sure which tags influx chooses to return
// perhaps only the ones in the WHERE clause
// grafana allows you to use tags in the alias pattern
"tags" : {
"foo" : "bar"
},
// I have not checked grafana's source but it's possible
// it does not read the "columns" array
"columns" : ["time", "mean"],
"values" : [
// time (in epoch ms), value
[1442953067791, 41.2]
]
}
]
}]
}

If you don't have your own InfluxDB instance up and you need to play
around with how Grafana sends it queries, you can use the test dashboard
http://play.grafana.org and your developer tools to take a peek.

As a disclaimer, I've probably missed something in how Grafana
communicates with InfluxDB, but the above was enough to get me started.

Hope that helps.

—
Reply to this email directly or view it on GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment-142419032.

The above terms reflect a potential business arrangement, are provided solely
as a basis for further discussion, and are not intended to be and do not
constitute a legally binding obligation. No legally binding obligations will
be created, implied, or inferred until an agreement in final form is executed
in writing by all parties involved.

This email and any attachments hereto may be confidential or privileged.
If you received this communication by mistake, please don't forward it to
anyone else, please erase all copies and attachments, and please let me
know that it has gone to the wrong person. Thanks.

:+1: for Postgres!

+1 for SQLite

@roybass - you post has given me an idea and i have made a very basic start on a postgres proxy - i have not actually pointed grafana at it yet but am hoping via influx custom queries it can pretend to be influx but is backed by postgres

sorry a link would be useful: https://github.com/sysadminmike/postgres-influx-mimic

hi everyone who wants to connect to postgres - i have managed to get the above working and have an example graph

+1 postgres / postgres with JSONB type
@EliSnow we use node, postgres, influxdb and grafana... if you can, I'd like to look at your code :)
@sysadminmike will check it out !

:+1: MySQL

@RobMcZag let me know what you think - I have used it for setting up a distributed metric collection idea: https://github.com/sysadminmike/yadms/

@torkelo, I am not sure how, a SQL datasource will scale with millions of datapoints being stored every day. I can agree on having a datasource as Cassandra which is highly scalable and awesome in performance.

@utkarshcmu, I guess it's fair to say that relational databases aren't slow by nature. Anyway, even if they were, it can still be attractive to pull out data from a small table for annotations or whatever, so SQL databases are a very useful source of data, if you ask me.

what is the latest on sql as data source?

+1 Informix TimeSeries / Informix TimeSeries w/ JSON
@utkarshcmu Informix is an example how an object relational DB can support a highly scalable time series data implementation through an optimized timeseries data type (time series elements can be SQL data types and/or JSON documents). ;)

Hello,

There is possibility to have SQL numeric data exported over HTTP interface using additional layer between SQL server and Grafana with the help of ArrestDB: https://github.com/alixaxel/ArrestDB
If someone could fork plugin from the existing HTTP based one that would be very nice. Personally I'm not an expert with Java coding here and need help with this.
This also would stack nicely with Restful API from other data sources - https://restdb.io/docs/rest-api

+1

Hi, here is my first project in go:
Collect Microsoft SQL Server metrics, send to InfluxDB and visualize with Grafana
https://github.com/zensqlmonitor/influxdb-sqlserver

+1 to MySQL :)

+1 for VoltDB [In-Memory SQL DB]

:+1:

How about jdbc?

+1 MySQL

+1 MySQL

+1 PostgreSQL

+1 PostgreSQL

WIP SQL datasource: https://github.com/grafana/grafana/pull/3964

+1 postgresql
On Feb 8, 2016 10:00 PM, "Tom Dyas" [email protected] wrote:

WIP SQL datasource: #3964 https://github.com/grafana/grafana/pull/3964

—
Reply to this email directly or view it on GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment-181722398.

+1 Cassandra

Hi, what is the status of a SQL datasource integration? For us it is of high interest to connect grafana to Amazon Redshift or Presto. There might be the option to put one of our developers on this topic. Is the SQL integration just some coding work or are there major changes required?

I had a work-in-progress prototype in PR https://github.com/grafana/grafana/pull/3964 talking to my company's Redshift. So I believe just coding work (on my part or someone else's) at this point. Although there are several items listed in the PR that would need to be accomplished before making it production-ready.

+1 VoltDB

+1 Would be useful for annotations and text panels.

+1

+1

I've been running influxdb proxied through grafana now for a while. As a side hobby I'm poking around with a web app firewall, and one thing I'd be really keen to find a solution to is something akin to prepared statements in order to preempt SQL injections. Right now, I have a collection of various regexes that detect sql injections, but finetuning those whilst retaining the capability to deploy new dashboards pretty much prevents that, leaving me no other option than to pretty much whitelist the argument section.
Conceptually, it would be simple: publish fixed proxy links for data collection created when the dashboard is created/updated, rather than have the query statement embedded in the argument of the url. All you'd have to do on the proxy side is map it to the real query and then send it over to the database backend.
Dealing with this via the proxy parts of grafana gives the added elegance of database independence on being able to deal with prepared statements.

:+1: for the concept/idea as well as the ability to use more-or-less raw SQL if you want to supplement existing methods/features/metrics

+1 for postgresql/mysql

todo mis dedos levantado para postgres

+1

+1

+1. Really need this!

+1

Any updates on this ??

I wrote an initial proof of concept which I put up as a PR to get feedback: https://github.com/grafana/grafana/pull/3964. The code worked fine for queries against a locally running PostgreSQL instance. I do not know if it would still work given source code changes in Grafana on the way to v3.

Unfortunately, I don't have the time to work on it anymore because the internal project that would have needed such a datasource, no longer does.

Given the source code for the proof of concept is publicly available in the PR, it would be nontrivial (but not a great amount of work) for someone else to take over. If you are a developer, this is a great way to learn the Grafana source code base. If you are not a developer, but have influence in your company, then I recommend convincing a developer in your organization to work on it.

This issue really demonstrates the "free rider" problem in open source. The "currency" of open source is code (in its broadest sense) and the time invested by contributors in that code. It seems to me everyone is happy to give a +1, but very few people contribute or use their influence to convince someone in their organization to contribute.

Want to influence the project's direction on this issue? Take over the proof of concept, complete it, and contribute it back, whether by doing it yourself or allocating your organization's time (in the form of a developer) to do it. That time allocation is most definitely an expenditure. Who's willing to "spend" the time?

For myself, I am willing to answer any questions about the proof of concept from whoever takes it over.

I sent pull request of this.

• https://github.com/grafana/grafana/pull/5168 "Add the datasource of RDBMS (PostgreSQL and MySQL) "
• You can see the detail of this:
  https://github.com/anzai/grafana/wiki/SQL-DB-plugin-%28datasource%29

+1

+1 for Postgres, my workplace loves Grafana already

We would love to see this - as a reference https://github.com/sirensolutions/kibi is a "friendly-fork" of kibana and sql support is one of the features they have added
https://github.com/sirensolutions/kibi/tree/master/src/plugins/kibi_core/lib/datasources

if this helps.

+1 for mysql/mariadb backend support (needed mainly to dig ticketing databases GLPI/OTRS/etc...)

Guys, please, stop posting +1. Just say thanks to @anzai and apply https://github.com/grafana/grafana/pull/5364 to your local grafana.

mysql and postgre is awesome, Oracle or generic jdbc would be awesome (like in Kibi mentioned above)

@Jimilian - the +1 is to get it into the main distribution. Applying the patch means that when a new grafana is released, I'll have to reapply, which most users don't want to deal with.

+1 for this feature, especially if it supports ODBC/JDBC

:+1: for postgres!! :-)

I took another approach to displaying data in RDBMS using RestSQL. RestSQL enables CRUD operations on relational databases and it's quite elegant solution to enable database operations using HTTP and REST methods.

I've written a Grafana plugin for RestSQL - Grafana plugin (3.x) for RestSQL. However consider it as a PoC at this time :-)

In my setup no changes to Grafana code base are needed. However this setup needs Java (Tomcat) for RestSQL to work.

+1. Awesome POC @juliusloman .

+1 . Would be really great for Postgres!

+1 Postgres!
+1 Raw SQL queries

+1 for cassandra!

@juliusloman Would be awesome if you published that plugin on grafana.net!

+1 MYSQL and POSTGRES with Raw Queries

+1 Postres!
+1 Cassandra!
+1 MySQL!

+1 Cassandra

+1 MySQL

+1 MS SQL!! :D

Instead of creating N +1 comments, I suggest adding a :+1: tag to the first line mentioning the DB you'd like to have supported ?

:+1:

+1 BigQuery.

So is this plugin going to official version? I would like to have Postgres as data source.

+1 PostgreSQL

@all I've open sourced my InfluxDB-to-MySQL protocol converter and published it to https://github.com/philip-wernersbach/influx-mysql, and it's ready to work with Grafana.

I would think that a JSON input gateway should suffice to allow practically any SQL input. I write the SQL to be executed through the proper driver, and the result JSON is consumed by grafana.

BigQuery datasets as configurable backends would be absolutely _powerful_.

+1 MySQL

@envintus If you have time to contribute, I'd love to have BigQuery support in https://github.com/philip-wernersbach/influx-mysql

sparkSQL +1

any update on the sql plugin?

having raw SQL support in grafana will definitely make it the best 👍
any updates on this topic?

My naive try grafana-simple-sql-datasource!
DISCLAIMER: unpolished&clunky beta version ... but works for me 🤣

https://github.com/gbrian/grafana-simple-sql-datasource

@gbrian looks good!

I'm new to sql-js proxies, and have a question.
There are different packages for different databases, like MySql, MSSql, Postgress...
Is it naive to think that your implementation will work with different DB's?
If so, how this could be addressed? looks like we need some kinda of abstraction in between...

@osigida, thanks!

Yep, main idea is to have a "xxxproxy.js" file for each SQL-like data source.

Next on my list is Apache Drill (https://drill.apache.org/)
If i did right it should be wasy as creating the proxy and setting up the connector like
http://simple-sql-server:port/?con=drill://drilluser:password@drill-server:port
of course the task is converting datasource schema to simple-sql.

I'll be glad if you test it and send me back some feedback. Please open as many issues you find and I'll try to fix them asap.

Thanks in advance.

@gbrian If you plan to implement Postgres. I'll be glad to help you and test.

great work. will this be for  oracle also?

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------From: Gustavo Brian notifications@github.com Date: 2/16/17 4:00 AM (GMT-05:00) To: grafana/grafana grafana@noreply.github.com Cc: gsaray101 gsaray101@yahoo.com, Comment comment@noreply.github.com Subject: Re: [grafana/grafana] Grafana 2.0: SQL Data source (#1542)
@osigida, thanks!
Yep, main idea is to have a "xxxproxy.js" file for each SQL-like data source.
Next on my list is Apache Drill (https://drill.apache.org/)

If i did right it should be wasy as creating the proxy and setting up the connector like

http://simple-sql-server:port/?con=drill://drilluser:password@drill-server:port

of course the task is converting datasource schema to simple-sql.
I'll be glad if you test it and send me back some feedback. Please open as many issues you find and I'll try to fix them asap.
Thanks in advance.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/grafana/grafana","title":"grafana/grafana","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/grafana/grafana"}},"updates":{"snippets":[{"icon":"PERSON","message":"@gbrian in #1542: @osigida, thanks!\r\n\r\nYep, main idea is to have a \"xxxproxy.js\" file for each SQL-like data source.\r\n\r\nNext on my list is Apache Drill (https://drill.apache.org/)\r\nIf i did right it should be wasy as creating the proxy and setting up the connector like \r\nhttp://simple-sql-server:port/?con=drill://drilluser:password@drill-server:port\r\nof course the task is converting datasource schema to simple-sql.\r\n\r\nI'll be glad if you test it and send me back some feedback. Please open as many issues you find and I'll try to fix them asap.\r\n\r\nThanks in advance."}],"action":{"name":"View Issue","url":"https://github.com/grafana/grafana/issues/1542#issuecomment-280272622"}}}

@anayrat , @gsaray101

Looks feasible and should be quite easy:
https://www.npmjs.com/package/pg
https://www.npmjs.com/package/strong-oracle

+1 MySQL

+1 MySQL

+1 Cassandra

+1 MSSQL +1 MYSQL

FYI

Now there is an official premium Oracle plugin (non-free)
https://grafana.com/plugins/grafana-oracle-datasource

https://github.com/grafana/grafana/pull/5364#issuecomment-290066384

HI @epizut: This premium plugin is under development as part of the overall effort. The premium plugin will take advantage of forthcoming core functionality.

More to come here!

Are there any known limitations of using cassandra as a grafana data source? Or any other concerns one should be aware of before implementing a datasource plugin?

Cassandra isn't a time series database so I don't think you can use it as a
data source in grafana. I am using opentsdb for my grafana data source

On May 19, 2017 10:28 AM, "mtnxplorer7" notifications@github.com wrote:

Are there any known limitations of using cassandra as a grafana data
source? Or any other concerns one should be aware of before implementing a
datasource plugin?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment-302763176,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARG51ZdZ6qbzst8m7mx-tsSZ9cRoBe5Lks5r7dEggaJpZM4DndgD
.

Cassandra supports time-series data modeling. Any thoughts based on this

+1 for Apache Drill.

I see the backend part of this PR has been merged but what's the overall status? Is there an ETA for a review and merge of any necessary frontend work?

For MySQL there is a backend part & frontend part, with alert support. No support for Postgres yet

Postgres support will be really cool to use with http://www.timescale.com/.

I would love to see SQL support for athena: http://docs.aws.amazon.com/athena/latest/ug/what-is.html

@torkelo I need assistance with the MySQL Datasource. I have the latest Grafana version installed (v4.4.3)

My grafana host is suppose grafana.host.org and I have an SQL database for an application that is hosted on a different host, let's say application.host.org. I have mysql db on the same application.host.org

When I add a new data source of type MySQL on grafana (i.e. grafana.host.org), it asks me connection details. I add the following details to it:

Host: application.host.org:3306
Database: dbname
User: dbuser
Password: dbpassword

Now when I save and test this connection, it gives me an error saying:

"Error 1045: Access denied for user 'dbuser'@'grafana.host.org' (using password: YES)"

Any leads on a solution to this? Why is it trying to access grafana.host.org when i have specified the db host as application.host.org? I can connect from grafana.host.org to application.host.org fine. However it gives me this error.

My understanding is, it should try to connect to the db on the application.host.org. When i connect to the db on that host on the backend, i get through without a problem.

Your help with thil will be much appreciated.

Thanks,
Jyoti

Error 1045: Access denied for user 'dbuser'@'grafana.host.org' (using password: YES)

This error is from MySQL. It has recognized that dbuser is connecting _from_ the network address that resolves to grafana.host.org. Check the permissions, password, etc at MySQL.

Any thoughts to supporting Redshift SQL dialect?

Redshift SQL is just Postgres 8.x family, which should be compatible with the recently-landed Postgres support. Haven't tried it yet but also interested if there's any errors.

If you dont mind proxying data through postgres you can connect grafana to (almost) any database with postgres foreign data wrapper (https://wiki.postgresql.org/wiki/Foreign_data_wrappers).

+1 Oracle DB

+1 for MS SQL

+1 for SQLite

hi, any one interested in mssql, please check pr #10093

Has anyone worked on Oracle as data source? I would love to see it.

@gsaray101 and anyone who's interested - contact [email protected] if you'd like to test the Oracle beta datasource.

We have merged the Microsoft SQL Server data source to Grafana and it will be released in Grafana 5.1 (#10093, #11298).

This means that Grafana now has support in core for MySQL, Postgres and MS SQL Server as data sources. We will not be adding any more sql databases as data sources to core Grafana so it is finally time to close this issue.

In the near future, we will have support for backend plugins so it will be possible to have other sql data sources as external plugins.

Anyone looking at adding DB2 LUW support?

@daniellee What about Oracle and SQLite? :thinking: Any news about this?

@mnlbox There is an Oracle plugin already: https://grafana.com/plugins/grafana-oracle-datasource (It is not open source however)

Sqlite as a datasource is not on our backlog at all and I haven't heard of anyone working on it.

+1 for Presto

Any update on SQLite @daniellee ?

SQLite datasource would be very useful!

Sqlite!!!!!

Sqlite !!!!!

Sqlite!!!!!

Sqlite !!!!!

Please use the 👍 function to show your approval and comment only if you can supply additional information, helpful notes, patches and similar - well - comments helping to solve the issue. Spamming developers, contributors or participants probably won't convince anyone to implement your requests.

Daniellee stated above there are no further efforts taken to support additional datasources in core and plugins are the way to go. Also no one seems to have started working on SQLite so far. If you need a quick and dirty solution and don't want to write/commission/adapt a whole plugin for/to SQLite it should be somewhat easy to build a smapp proxy-script to serve your SQLite-data as JSON similar to doublemarkets RRD-Proxy. Not a great solution speedwise, but you probably wouldn't be using SQLite if thats a concern.

As @adlerweb says, there are currently no plans for the core Grafana team for a core Sqlite datasource. I don't think we would accept a PR for it either. However, we would of course, publish an external datasource plugin on grafana.com if someone wrote it.

Any update on SQLite @daniellee ?

For those interested in SQLite support (or in fact those who wait for any data source), you don't need to wait long. It's pretty easy to write your own data source using Python. The documentation is a bit sparse (see https://github.com/grafana/simple-json-datasource), but it's possible. I have created a fairly extensive example in this repository and a blog post on how to visualize SQLite with Grafana . The repository also includes a working example of SQLite and a small database for this example.

• SQLite vote !

vote for sqlite

With the backend comes the possibility to have SQL data source.

My thinking is that when you add the data source you

• db type (initially only mysql and postgres and sqlite3)
• db connection details
• specify a metric query template (basically a SQL query with params)
• specify a annotation query template

Maybe also an option to allow RAW SQL queries from the panel metric query interface.

Any other ideas?

For Sqlite

Vote for sqlite.

Sqlite plsss